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PRÉFACE 


Le livre du Professeur G. GARDARIN traite un sujet particulièrement dif- 
Jicile de l'informatique des systèmes : les bases de données. Plusieurs repères 
soulignent cette difficulté. Les systèmes les plus utilisés aujourd’hui s'appuient 
sur des notions datant pratiquement de 20 ans, or ces notions ne sont pas totale- 
ment satisfaisantes ; elles subsistent car on n'a pas encore su trouver et réaliser 
mieux. La nouvelle génération que constituent les systèmes relationnels est arri- 
vée beaucoup plus tard que prévue ; la conception de l'un d'entre eux a pris plus 
de 10 ans et il faut encore attendre pour répondre à la question « ces systèmes 
sont-ils utilisables intensément et efficacement ? ». Universitaires et chercheurs 
publient de nombreux résultats en bases de données, mais la traduction en 
terme de systèmes réalisés par des praticiens, utilisés sur une grande échelle, est 
toujours attendue. 


Ce qui précède ne signifie nullement que les bases de données soient un 
domaine en stagnation, au contraire deux signes parmi d'autres témoignent 
d'importants progrès réalisés ces dernières années. Si une base de données est 
volumineuse, gérée en temps réel, il y aura de nombreuses demandes pour y 
accéder simultanément en traitement par lots ou bien interactif ; or il existe 
aujourd'hui plusieurs systèmes qui réalisent complètement ce type d'accès 
concurrent. En matière de langage de manipulation de données, il est clair que 
l'idéal d'adaptation de la machine à l'homme est le langage national de chaque 
utilisateur ; le modéle relationnel est une étape positive vers ce résultat (dont 
nous sommes pourtant encore éloignés). 





val Bases de données 


Le Professeur G. GARDARIN est à la fois un réalisateur de systèmes — il 
a contribué aux Systèmes Ordoprocesseurs —, un chercheur qui a publié — 
comme par exemple aux congrès « Very Large Data Bases » et dans des revues 
telles ACM Transactions on Database Systems et IEEE Transactions —, et un 
enseignant de l’Université Paris VI ; son livre traduit cette complémentarité des 
points de vue sur les bases de données. 


Les chapitres sur les systèmes dé Gestion de Fichiers, sur l'architecture de 
systèmes opérationnels, sur les langages de manipulation de données relation- 
nelles, sur les modéles d'accés et langage navigationnels sont ceux d'un prati- 
cien qui connaît et compare les systèmes réels. Les quelques cent cinquante réfé- 
rences à des publications, le long chapitre sur le contrôle des accès concurrents, 
la formulation de résultats en terme de théorèmes, l'établissement de leur 
preuve sont ceux d'un chercheur qui fait rigoureusement le point de la question 
pour faire avancer la réponse. Enfin, il faut souligner que le livre a été écrit par 
l'enseignant, c'est lui qui établi la définition des notions pratiques et théoriques, 
ne néglige jamais un dessin pour mieux communiquer, offre sans cesse au lec- 
teur un fil pédagogique. 


Ce livre ne prétend pas répondre à la question ouverte de l'évolution des 
bases de données, il fait le point de manière synthétique et objective de l'état de 
la question. Les connaissances qu'il présente sont nécessaires à l'informaticien 
systéme qu'il soit utilisateur, réalisateur, chercheur ou étudiant. 


Michel ROCHER 
Directeur du Logiciel, CII-HB 
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l. INTRODUCTION 


1. NOTION DE SGBD 


Les Bases de Données ont fait couler beaucoup d'encre et ont 
aujourd'hui pris une place essentielle dans les systémes informatiques, 
tant du point de vue pratique que théorique. Ainsi, la plupart des systé- 
mes, y compris les micro-systémes d'informatique individuelle, offrent 
aujourd'hui un Systéme de Gestion de Bases de Données (SGBD). En 
conséquence, le lecteur a sans doute une notion intuitive des bases de 
données. Qu'il prenne garde car ce mot est souvent utilisé pour désigner 
n'importe quel ensemble de données : il s'agit là d'un abus de langage 
qu'il faut éviter. Nous espérons que la lecture de cet ouvrage vous per- 
mettra d'avoir une notion plus précise de ce qu'est une base de données 
et de mieux utiliser dans le futur les Systémes de Gestion de Bases de 
Dennées que vous ne manquerez pas de rencontrer. 


Plutót que de définir le concept de base de données, nous préférons 
préciser tout d'abord intuitivement ce qu'est un Système de Gestion de 
Bases de Données (SGBD). Un SGBD est un écran entre les usagers et 
les mémoires secondaires qui tend à créer l'illusion que les données dési- 
rées par tout usager sont stockées sur mémoires secondaires, assemblées 
et codées comme souhaitées, comme si l'usager était seul à utiliser ces 
données. Un SGBD est aussi et surtout un outil permettant d'insérer, de 
modifier et de rechercher efficacement des données spécifiques dans une 
grande masse d'informations (quelques milliards d'octets) partagées par 
tous les usagers. Les recherches peuvent être exécutées à partir du nom 
d'une donnée (par exemple TEMPÉRATURE) ou de ses relations avec 
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d’autres données (par exemple TEMPÉRATURE MOYENNE A PARIS 
EN JANVIER). Un SGBD est en général composé d’un ensemble de logi- 
ciels, mais peut aussi comporter des éléments matériels spécialisés. 


En résumé, un SGBD peut donc apparaître comme un outil de ran- 
gement, de recherche, d’assemblage et de conversion des données. Ce 
sont là des fonctions premières complétées par des fonctions souvent 
plus complexes, afin de protéger les données contre tout incident ou acci- 
dent et d’obtenir des performances acceptables de la part du système. 
Les SGBD se distinguent clairement des systèmes de fichiers par le fait 
qu'ils permettent la description des données (définition des noms, for- 
mats et caractéristiques) de manière séparée de leur utilisation (mise à 
jour et recherche). 


Un SGBD se compose en première approximation de trois couches 
successives de fonctions, empilées depuis les mémoires secondaires vers 
les usagers : 


— la gestion des récipients de données sur mémoires secondaires com- 
pose traditionnellement la première couche ; c’est le système de gestion 
de fichiers ; ` 

— la gestion des données stockées dans les fichiers, le placement et 
l’assemblage de ces données, la gestion des liens entre données et des 
structures permettant de les retrouver rapidement constituent la 
deuxième couche ; c’est le système d’accès aux données ou SGBD interne 
qui devient de plus en plus invisible aux programmes d’applications ; 
— la présentation des données aux programmes d’applications et aux 
usagers terminaux ayant exprimé leurs besoins en données à l’aide de 
langages plus ou moins élaborés, constitue la fonction essentielle de la 
troisième couche : c’est le SGBD externe qui assure d’une part, l’analyse 
et l'interprétation des requêtes des usagers, d'autre part, la mise en 
forme des données échangées avec le monde extérieur. 


La figure I.1 illustre ces trois couches de fonctions qui constituent 
un SGBD. 


A partir de la notion de SGBD, une base de données peut être défi- 
nie comme un ensemble de données géré par un SGBD et associées à 
une méme application. La notion d'application étant trés large dans le 
domaine des bases de données, les spécialistes parlent souvent d'entre- 
prise. Ainsi, une base de données est un ensemble de données géré par un 
SGBD et modélisant une méme entreprise. Un ensemble de fichiers n'est 
donc pas en général une base de données, contrairement à l'idée couram- 
ment répandue. 
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Fig. 1,1. — Première vue d'un SGBD. 
P.A. = Programme d'Application ; M.S. = Mémoires secondaires 


2. HISTORIQUE DES SGBD 


Les SGBD ont déjà une longue histoire. Les années 60 ont connu un 
premier développement des systémes de fichiers qui tendent essentielle- 
ment à faire apparaitre les mémoires secondaires comme idéales, parta- 
gées, banalisées, directement adressables, de capacité infinie. Ceux-ci, 
après avoir évolué, composent aujourd'hui le cœur des SGBD. 


Le milieu des années 60 a vu la naissance de la premiére génération 
de SGBD ; celle-ci a été marquée par la séparation de la description des 
données des programmes d'application et l'avénement de langages 
d'accés navigationnels, c'est-à-dire permettant de se déplacer dans des 
Structures de type graphe et d'obtenir, un par un, des groupes de don- 
nées appelés articles. Cette premiére génération, caractérisée par les 
systémes obéissant aux premiéres recommandations du CODASYL et 
par IMS d'IBM, est basée sur des modèles d'accés, c'est-à-dire des 
modèles de données visant essentiellement à optimiser les méthodes de 
placement des données sur les mémoires secondaires afin de réduire les 
temps d'accés. 


La deuxiéme génération de SGBD a grandi dans les laboratoires 
depuis 1970, à partir du modèle relationnel. Elle vise essentiellement à 
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enrichir le SGBD externe afin de simplifier l’accès aux données pour les 
utilisateurs externes. Ainsi, la deuxième génération offre des langages 
assertionnels basés sur la logique, permettant de spécifier les données 
que l’on souhaite obtenir sans dire comment les accéder. C’est le système 
qui doit déterminer le meilleur plan d’accès possible. Cette deuxième 
génération reprend, après les avoir fait évoluer et rendu plus dynami- 
ques, certains modèles d’accès de la première génération au niveau du 
SGBD interne, afin de mieux optimiser les accès. Les premiers systèmes 
de deuxième génération sont commercialisés seulement depuis le début 
des années 80 et demandent encore à faire leurs preuves. 


Déjà, une troisième génération de SGBD basée sur des langages 
d'accés plus puissants et plus naturels, supportant des types de données 
plus variés, incluant des possibilités de déduction et de répartition, est à 
l'étude dans les laboratoires de recherche. 


3. OBJECTIFS DU LIVRE 


Ce livre se propose de faire le point sur les problémes essentiels qui 
sont aujourd'hui résolus par les SGBD, ainsi qu'un tour d'horizon des 
diverses solutions possibles. Il explique donc comment sont bátis les 
SGBD de premiére et deuxiéme génération, et présente leurs langages 
externes. Il tente de dégager les principales notions des SGBD des années 
80, notions qui sont numérotées au niveau de chaque chapitre. 


Ce livre est le résultat d'un cours sur les bases de données dispensé à 
l'Université de Paris VI depuis plusieurs années. Le cours a pour objec- 
tifs de conduire l'étudiant à peine familiarisé avec les systèmes d'exploi- 
tation à devenir un spécialiste des SGBD actuels, capable de bien utiliser 
de tels systémes mais aussi d'en construire. 


4. PLAN DU LIVRE 


Il apparaît finalement difficile de concevoir le plan d'un livre trai- 
tant des systémes de bases de données, tant est vaste le sujet et tant sont 
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imbriqués les problèmes. Nous avons choisi deux critères essentiels pour 
bâtir notre plan : 

— faire des chapitres aussi indépendants que possible ; 

— aller des problèmes bien connus, tels la gestion des fichiers, vers les 
problèmes plus ouverts, tels la sécurité des données et l'évaluation de 
questions complexes. 


L'approche se veut donc essentiellement pédagogique. 


En résultat, le livre comporte huit chapitres essentiels. Le chapitre II 
tente de faire le point sur les systémes de fichiers, en particulier sur les 
méthodes d'accès. Il peut être sauté par le lecteur averti ou pressé, ou qui 
considérerait les fichiers comme un probléme dépassé (bien qu'il n'en 
soit rien). Le chapitre III introduit les objectifs essentiels des SGBD et 
précise les architectures des systémes. Les recommandations des groupes 
de normalisation ainsi que les architectures des systémes actuels et futurs 
sont examinées. Le chapitre IV présente le modèle relationnel et la théo- 
rie associée de la normalisation. Cette théorie connaît aujourd'hui des 
développements nouveaux qui devraient la rendre plus applicable ; ces 
développements sont abordés. Le chapitre V décrit les principaux langa- 
ges des systémes relationnels. Ce sont les langages des systémes de 
deuxiéme génération qui permettent de spécifier les données que l'on 
désire sans dire comment les retrouver. Le chapitre VI présente les modé- 
les d'accès des SGBD de première génération (modèle réseau et hiérar- 
chique) et les langages de manipulation associés. C'est là la base de la 
plupart des systémes commercialisés depuis 1970. Finalement, les trois 
autres chapitres traitent des problémes spécifiques à la réalisation des 
SGBD : 


— le probléme du contrôle des accès concurrents et du partage des don- 
nées est étudié au chapitre VII. C'est là un probléme difficile qui a fait 
couler beaucoup d'encre ; 

— le probléme de la sécurité des données en présence de pannes et 
d'accés non autorisés, voire mal intentionnés, est traité au chapitre VIII. 
Le bon traitement de ces problémes est essentiel pour l'utilisation en 
toute confiance des SGBD ; 

— le probléme de l'optimisation des temps de réponse et du traitement 
des questions qui restent la clé du succés des SGBD de 2* génération est 
étudié au chapitre IX. 


En conclusion, les nouveaux axes de développement des SGBD sont 
abordés. Leur étude dépasse le cadre de cet ouvrage. 
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Il. LA GESTION DES FICHIERS 


1. INTRODUCTION 


Les systémes de gestion de bases de données sont souvent considérés 


comme un premier niveau de programmes d'application utilisant un 
Systéme d'exploitation. Les fonctions essentielles assurées par les systé- 
mes d'exploitation sont (cf. fig. II.1) : 
— la Gestion de la Mémoire qui permet le partage de la mémoire entre 
les programmes ; 
— la Gestion des Processus qui permet l'exécution de plusieurs pro- 
grammes usagers et systèmes simultanément, au moins en apparence ; 
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Fig. 11. — Composants d'un système d'exploitation 





8 Bases de données 


— Ja Gestion des Entrées-Sorties physiques qui assure l'échange de don- 
nées entre les unités périphériques et l'unité centrale ; 

— ]a Gestion des Communications qui effectue le transport de données 
vers, ou en provenance, d'autres unités ou processus ; 

— ]a Gestion des Programmes Usagers qui assure leur transformation 
en programmes exécutables et le contróle de leur exécution sous forme 
de processus ; 

— ]a Gestion des Fichiers qui permet le stockage de données sur mémoi- 
res secondaires. 


Nous allons, dans ce chapitre, étudier plus spécifiquement la gestion 
des fichiers. Un fichier est un récipient de données identifié par un nom 
et contenant des données. La gestion des fichiers est une des fonctions 
essentielles offertes par les systèmes. C'est, en effet, grâce à cette fonc- 
tion qu'il est possible de traiter et conserver des quantités importantes de 
données et de partager ces données entre plusieurs programmes. De plus, 
elle sert, en général, de base aux systèmes de Gestion de Bases de Don- 
nées que nous allons étudier dans les chapitres suivants. 


Dans ce chapitre, tout d’abord, les objectifs de la gestion des 
fichiers sont développés. Puis les fonctions accomplies par le noyau d’un 
gestionnaire de fichiers sont ébauchées. Enfin, et c’est l’objet essentiel 
du chapitre, les principales organisations et méthodes d’accès des fichiers 
sont étudiées. 


2. OBJECTIFS DE LA GESTION DES FICHIERS 


2.1. — Possibilités d'informatiser la gestion d'une grande entreprise 


Un gestionnaire de fichiers doit permettre le traitement par l'infor- 
matique de la gestion d'une entreprise. Les données descriptives des 
objets gérés par l'entreprise, ainsi que les données spécifiant les traite- 
ments appliqués aux objets, doivent pouvoir étre stockées dans les 
mémoires d'un calculateur. Les traitements de ces données peuvent étre 
exécutés par lots, en fin de mois par exemple, ou en fin de semaine.., 
mais aussi (et c'est en général plus difficile) à l'unité dés que survient un 
événement dans le monde réel : on parle alors de traitement transaction- 
nel. 


A titre d'illustration, un gestionnaire de fichiers devrait par exemple 
permettre de traiter l'application comptabilité d'une société de livraison. 


La gestion des fichiers 


Cette application est représentée figure II.2. Elle gère les comptes des 
clients et édite les factures suite aux livraisons. Pour calculer les mon- 
tants à facturer et à déduire des comptes clients, un catalogue des prix est 
utilisé, Les traitements peuvent être effectués en traitement par lots, en 
fin de mois ; dans ce cas, les bordereaux de livraisons du mois seront 
traités ensemble, par exemple à partir d’un fichier cartes. Le traitement 
d’une livraison peut aussi être effectué en transactionnel ; dans ce cas, la 
description de la livraison est tapée en direct sur un terminal et les traite- 
ments associés sont immédiatement exécutés. 


Livraisons 











Catalogue 


des prix 







COMPTABILITÉ 


Compte 
clients 










Compte 
clients 





Fig. 11.2. — Un exemple d'application 


2.2. — Utilisation de disques magnétiques 


L'informatisation de la gestion d'une grande entreprise nécessite le 
stockage de volumes de données importants, par exemple quelques cen- 
taines de millions d'octets voire plusieurs milliards. Il n'est pas possible 
de stocker de tels volumes de données en mémoire centrale. On est par 
suite conduit à introduire des mémoires secondaires. 


Notion 1 : Mémoire secondaire (External Storage) 

Mémoire non directement adressable par les instructions du processeur central, mais par 
des instructions d'entrée-sortie spécialisées et dont les temps d'accés sont trés supé- 
rieurs à ceux de la mémoire centrale. 


Un cas particulier de mémoires secondaires est le disque magnétique 
[IBM78]. La capacité des disques s'est accrue depuis les années 1965 
pour atteindre quelques 100 millions d'octets aujourd'hui. Les temps 
d’accès se sont également améliorés pour avoisiner aujourd’hui 10 ms en 
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moyenne. À noter qu’ils restent cependant environ 20 000 fois plus élevé 
que ceux des mémoires centrales : c’est-à-dire qu’entre un accès à des 
informations en mémoire et un accès disque, il y a le même rapport 
qu’entre un jour et 55 ans, ou un an et 20 000 ans ! 


Pour traiter correctement de grandes applications, il est nécessaire 
de disposer d’une capacité infinie de mémoires secondaires. Dans ce but, 
on utilise des piles de disques amovibles appelées volumes. 


Notion 2 : Volume (Disk pack) 
Unité de mémoire secondaire amovible. 


Un volume disque est monté sur un tourne-disque. Un contrôleur de 
disques contrôle en général plusieurs tourne-disques. Les volumes sont 
montés et démontés par les opérateurs, en général sur ordre du système. 
La notion de volume s’applique également aux bandes magnétiques où 
un volume est une bande. Une unité peut alors comporter un ou plu- 
sieurs dérouleurs. 


Un volume ainsi que l'équipement de lecture-écriture associé à un 
tourne-disque est représenté figure II.3. Un volume se compose de p dis- 
ques (par exemple 9), ce qui correspond à 2 p — 2 surfaces magnétisées 
car les deux faces externes ne le sont pas. Les disques à tétes mobiles com- 
portent une téte de lecture-écriture par surface. Cette téte est accrochée 
à un bras qui se déplace horizontalement de maniére à couvrir toute la 
surface du disque. Un disque est divisé en pistes concentriques numéro- 
tées de 0 à n (par exemple n — 512). Les bras permettant de lire/écrire 
les pistes d'un volume sont solidaires ce qui force leur déplacement simul- 
tané. Les disques tournent continüment à une vitesse de quelques dizai- 
nes de tours par seconde. L'ensemble des pistes décrit quand les bras sont 
positionnés est appelé cylindre. Il existe également des disques à tétes fixes 
qui comportent une téte de lecture/écriture par piste. 


Chaque piste d'un disque supporte plusieurs enregistrements physi- 
ques appelés secteurs, de tailles constantes ou variables selon le type de 
disque. Le temps d'accés à un secteur est une des caractéristiques essen- 
tielles des disques. Il se compose : 

— du temps nécessaire au mouvement de bras pour sélectionner le bon 
cylindre (quelques millisecondes à des dizaines de millisecondes selon 
l'amplitude du déplacement du bras et le type de disque) ; 

— du temps de rotation du disque nécessaire pour que l'enregistrement 
physique désiré passe devant les tétes de lectures-écritures ; ce temps est 
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appelé temps de latence ; il est de quelques millisecondes, selon la posi- 
tion de l’enregistrement par rapport aux têtes et selon la vitesse de rota- 
tion des disques. 


Piste 






































Bras 


Têtes de Disques Cylindre 
lectures/écritures 


Fig. 11.3. — Vo/ume amovible à têtes mobiles et équipement de lecture/écriture 


Au total, les disques ont un temps d’accès variable selon la distance 
qui sépare l'enregistrement à accéder de la position des têtes de lecture- 
écriture. La tendancé aujourd'hui est de réduire cette variance avec des 
moteurs à accélération constante pour commander les mouvements de 
bras, et avec des quantités d'informations enregistrées par cylindres de 
plus en plus importantes. 


2.3. — Indépendance entre les programmes d'applications et les 
mémoires secondaires 


Les disques magnétiques et plus généralement les mémoires secon- 
daires doivent bien sür pouvoir &tre utilisés par plusieurs programmes 
d'application. En conséquence, il faut pouvoir partager l'espace mémoi- 
res secondaires entre les données des diverses applications. Une gestion 
de cet espace et des adresses associées directement par les programmes 
d'applications est impraticable. Autrement dit, les programmes doivent 
être indépendants de l'emplacement des données sur disques. 


D'un autre côté, les progrès technologiques ne cessent d'améliorer 
le rapport performance/prix des mémoires secondaires. La densité des 
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disques magnétiques (nombre de bits enregistrés/cm?) double approxi- 
mativement tous les deux ans, ce qui permet d'accroître les capacités de 
stockage et les performances. Un bon systéme doit pouvoir permettre 
aux utilisateurs de profiter des avancées technologiques, par exemple en 
achetant des disques plus performants, et ceci, sans avoir à modifier les 
programmes. En effet, la reprogrammation coûte trés cher car une per- 
sonne réalise environ 2 000 lignes de programmes par an, ce qui est peu. 
En résumé, il est possible de définir simplement l'indépendance des pro- 
grammes d'applications par rapport aux mémoires secondaires comme 
suit. 


Notion 3 : Indépendance entre programmes et mémoires secondaires (Program-Storage device 
Independance} 
Possibilité de changer les données de mémoire secondaire sans changer les programmes. 


Afin de réaliser cette indépendance, on introduit des objets intermé- 
diaires entre les programmes d’applications et la mémoire secondaire 
appelés fichiers. 


Notion 4 : Fichier (File) 

Récipient d'informations constituant une mémoire secondaire idéale caractérisé par un 
nom permettant d'écrire des programmes d'applications indépendants des mémoires 
secondaires. 


Ainsi, les programmes d'applications ne connaissent pas les mémoires 
secondaires mais les fichiers qui peuvent être implantés sur diverses 
mémoires. 


Un programme d'application ne manipule pas globalement un 
fichier mais lit/écrit et traite des portions successives, correspondant en 
général à un objet du monde réel, par exemple un client, un compte, une 
facture. Une telle portion est appelée article. 


Elément composant d'un fichier correspondant à l'unité de traitement par les programmes 


| tène 5 : Article (Record) 
d'applications. 


Les articles sont reliés entre eux pour composer un fichier. Les structures 
des liaisons constituent l'organisation du fichier. 


| Notion 6 : Organisation de fichier (File organization) 
Nature des liaisons entre articles pour composer un fichier. 


Les programmes d’applications peuvent choisir un article dans un fichier 
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de différentes manières, par exemple l’un après l’autre à partir du pre- 
mier, ou en attribuant un nom à chaque article, selon la méthode d’accès 
choisie. 


Méthode d'exploitation du fichier utilisée par les programmes d'applications pour sélec- 


|o 7 : Méthode d'accès (Access Method) 
tionner des articles. 


Ces différentes notions vont nous permettre de réaliser l’indépen- 
dance désirée entre mémoires secondaires et programmes d'applications. 


2.4, — Utilisation de langages hótes 


Le systéme de gestion de fichiers doit étre utilisable par un pro- 
gramme dont le code objet résulte d'une compilation d'un langage de 
haut niveau (COBOL, PL1, PASCAL...). De plus, il doit être possible 
d'utiliser les fichiers dans le langage choisi d'une maniére aussi intégrée 
que possible, par exemple en décrivant les données du fichier comme des 
types dans le langage. On appelle langage hóte le langage de programma- 
tion qui intégre les verbes de manipulation de fichiers. 


Notion 8 : Langage hôte (Host language) 
Langage de programmation accueillant les verbes de manipulation de fichiers et la défini- 
lion des données des fichiers. 


PROGRAMME 
Y 
COMPILATEUR 


CODE MACHINE 
RANSLATABLI 








Fig. 11.4. = Cheminement CODE MACHINE 
d'un programme XECUTABLE 
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Il est utile de rappeler le cheminement d'un programme en machine. 
Celui-ci est donc écrit à l'aide d'un langage de programmation hóte et de 
verbes de manipulation de fichiers. Il est pris en charge par le compila- 
teur du langage. Celui-ci génère du code machine translatable incluant 
des appels au systéme, en particulier au gestionnaire de fichiers. Le 
chargeur-éditeur de liens est ensuite chargé d'amener en bonne place en 
mémoire les différents modules composants du programme ; en particu- 
lier, les translations d'adresses doivent étre effectuées à ce niveau. On 
obtient alors du code exécutable. La figure II.4 illustre ces étapes. 


2.5. — Possibilités d'accès séquentiel et sélectif 


Afin de caractériser le comportement des programmes d'applica- 
tions vis-à-vis des fichiers, il est possible d'utiliser deux mesures. Letaux 
de consultation (TC) est le quotient du nombre d'articles utilement lus 
par un programme sur le nombre d'articles total du fichier. Le taux de 
mouvement (TM) est le quotient du nombre d'articles modifiés par un 
programme sur le nombre d'articles total du fichier. 


Deux cas sont nettement distingables à partir de ces deux mesures. 
En traitement par lot, selon que le programme lit ou écrit, TC ou 
TC + TM sont souvent voisins de 1. En transactionnel, au contraire, ils 
restent voisins de 1/m, où m est le nombre d'articles total du fichier. On 
est ainsi conduit à introduire deux types de méthodes d'accés. 


Méthode d'accès consistant à lire successivement tous les articles d'un fichier, depuis le 


Ie 9 : Méthode d'accès séquentielle (Sequential Access Method) 
premier jusqu'au dernier désiré. 


Une telle méthode est adaptée dans le cas où TC ou TC + TM sont de 
l'ordre de 1. Elle sera essentiellement utilisée en traitement par lots. 


Ensemble de méthodes d'accès permettant de lire/écrire tout article au moyen de quel- 


| 10 : Méthodes d'accès sélectives (Key based access methods) 
ques accés disques (moins de 5, idéalement 1), y compris pour de trés gros fichiers. 


De telles méthodes seront utilisées quand TC, ou TC + TM pour 
un programme modifiant, sera petit. Elles sont donc particuliérement 
adaptées au transactionnel. 


Un gestionnaire de fichiers doit à la fois supporter des méthodes 
d'accés séquentielles et sélectives, ceci afin de permettre à la fois les trai- 
tements par lots et le travail transactionnel. 
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2.6. — Possibilité d'utilisateurs multiples 


Dans les machines modernes, l'exécution d'une instruction 
d'entrée-sortie ne bloque pas le processeur central : celui-ci peut conti- 
nuer à exécuter des instructions machines en paralléle à l'exécution de 
l'entrée-sortie. Afin d'utiliser ces possibilités, le systéme exécute plu- 
sieurs programmes usagers simultanément, ce qui conduit à une simulta- 
néité inter-usagers. 


Notion 11 : Simultanéité inter-usagers (Inter-user parallelism) 
Type de simultanéité consistant à exécuter un programme d'application en processeur 
central pendant qu'un autre programme effectue des entrées-sorties. 


Un bon systéme de fichiers doit permettre le partage des fichiers par 
les différents programmes d'applications sans que ceux-ci s'en aperçoi- 
vent. Le partage peut étre simultané, mais aussi plus simplement réparti 
dans le temps. 


2.7. = Sécurité et protection des fichiers 


L'objectif sécurité des fichiers contre les accés mal intentionnés, ou 
plus simplement non autorisés, découle directement du besoin de parta- 
ger les fichiers. En effet, lorsque les fichiers sont partagés, le propriétaire 
désire contróler les accés, les autoriser à certains, les interdire à d'autres. 
C'est là une des fonctions que doit rendre un bon service de gestion de 
fichiers. Ces mécanismes sont généralement réalisés à l'aide de noms 
composés et de clés de protection associés à chaque fichier, voire à cha- 
que article ; l'usager doit fournir ces noms et ces clés pour accéder au 
fichier ou à Particle. Nous étudierons les solutions dans le cadre des 
bases de données oü le probléme devient plus aigu. 


Le gestionnaire de fichiers doit aussi garantir la conservation des 
fichiers en cas de panne du matériel ou du logiciel. En conséquence, il 
doit étre prévu de pouvoir repartir aprés panne avec des fichiers corrects. 
On considére en général deux types de pannes : les pannes simples avec 
seulement perte du contenu de la mémoire centrale, et les pannes catas- 
trophiques où le contenu des mémoires secondaires peut être détruit. 
Ainsi, il est nécessaire d'incorporer des procédures de reprise aprés pan- 
nes simples et catastrophiques. Nous étudierons ces procédures dans le 
cadre des bases de données où elles sont généralement plus complètes. 
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3. LES FONCTIONS DU NOYAU D'UN GESTIONNAIRE DE FICHIERS 


Un gestionnaire de fichiers est généralement organisé autour d'un 
noyau qui assure les fonctions de base, à savoir la création/destruction 
des fichiers, l'allocation de la mémoire secondaire, la localisation et la 
recherche des fichiers sur les volumes, la gestion des tampons... Les 
méthodes d'accés sont des modules spécifiques qui constituent une cou- 
che plus externe et qui utilisent les fonctions du noyau. Ci-dessous, nous 
étudions les fonctions essentielles du noyau. 


3.1. — Manipulation des fichiers 


Le programmeur travaillant au niveau du langage machine, ainsi 
que les modules méthodes d'accés, accèdent au noyau du gestionnaire de 
fichiers à l'aide d'un ensemble d'instructions de manipulation de 
fichiers. Tout d'abord, deux instructions permettent de créer et détruire 
un fichier. Puis, avant de lire ou écrire des données dans un fichier, il 
faut contróler son identité ainsi qu'ouvrir un chemin pour les données 
entre le programme effectuant les lectures-écritures et la mémoire secon- 
daire. Ceci est généralement effectué par une instruction d'ouverture : 
ouvrir. L'opération inverse est exécutée lorsque le programme se désinté- 
resse du fichier par une instruction de fermeture : fermer. 


3.2. — Adressage relatif 


Un fichier étant généralement discontinu sur mémoire secondaire, il 
est utile de pouvoir adresser son contenu à l'aide d'une adresse continue 
de 0 à n appelée adresse relative. Cela présente l'intérét de disposer d'un 
repérage indépendant de la localisation du fichier sur mémoire secon- 
daire (en cas de recopie du fichier, l'adresse relative ne change pas) et de 
pouvoir assurer que l'on travaille bien à l'intérieur d'un fichier sans ris- 
que d'atteindre un autre fichier (il suffit de contróler que l'adresse rela- 
tive ne dépasse pas la taille du fichier). 


Notion 12 : Adresse relative (Relative address) 
Numéro d'unité d'adressage dans un fichier (autrement dit : déplacement par rapport au 
début du fichier). 


Pour réaliser l'adressage relatif, on divise généralement le fichier en 
pages (on trouve également selon les constructeurs les termes de bloc, 
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groupe, paquet, intervalle, bucket) : une adresse relative octet se com- 
pose alors d'un numéro de page suivi d'un numéro d'octet dans la page. 
Pour éviter un nombre trop important d'entrées-sorties, la taille de la 
page est généralement un nombre entier d'enregistrements physiques et 
des tampons d'une page sont utilisés. La taille de la page, fixée lors de la 
création du fichier, est le plus souvent de l'ordre de quelques K octets. 
Elle dépend en général de l'organisation du fichier. Ainsi, le premier 
niveau de logiciel composant un service de gestion de fichiers offre géné- 
ralement la possibilité d'accéder à une ou plusieurs pages d'adresse rela- 
tive (numéro de page) donnée dans un fichier. Il se compose essentielle- 
ment d'algorithmes d'allocation de mémoires secondaires et de conver- 
sion d'adresse relative page en adresse réelle de l'enregistrement physi- 
que, et réciproquement. Finalement, il permet de banaliser toutes les 
mémoires secondaires, avec quelques restrictions cependant : il est, par 
exemple, interdit d'accéder autrement qu'en séquentiel à une bande 
magnétique. 


Les articles de l'usager sont alors implantés dans les pages par les 
méthodes d'accés selon l'organisation choisie. Si plusieurs articles sont 
implantés dans une méme page, on dit qu'il y a blocage. Dans le cas où 
les articles sont implantés consécutivement sans trou à la suite les uns des 
autres, on dit qu'il y a compactage : aucune place n'est alors perdue sur 
la mémoire secondaire, mais des articles peuvent être à cheval sur plu- 
sieurs pages. 


8.3. — L'aliocation de la place sur mémoires secondaires 


La taille d'un fichier est fixée soit de maniére statique lors de sa 
création, soit de maniére dynamique au fur et à mesure des besoins. Des 
solutions intermédiaires sont possibles avec une taille initiale extensible 
par paliers. Dans tous les cas, il est nécessaire de réserver des zones de 
mémoires secondaires continues appelées régions pour le fichier. 


Notion 13 : Région (Allocation area) 
Ensemble de zones de mémoires secondaires (pistes) adjacentes allouées en une seule 
fois à un fichier. 


Comme les fichiers vivent et sont de tailles différentes, les régions 
allouées à un fichier ne sont généralement pas contigués sur une mémoire 
secondaire. Le gestionnaire de fichiers doit pouvoir retrouver les régions 
composant un fichier. Pour cela il peut, soit garder la liste des régions 
allouées à un fichier dans une table, soit les chainer, c'est-à-dire mettre 
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dans une entrée d’une table correspondant à chaque région l’adresse de 
la région suivante. 


La taille d’une région peut varier à partir d’un seuil minimal appelé 
granule (par exemple une piste, etc.). 


Notion 14 : Granule d'allocation (Allocation granule) 
Unité de mémoire secondaire allouable à un fichier. 


Lorsqu'un fichier est détruit ou rétréci, les régions qui lui étaient allouées 
(ou une partie) sont libérées. 


3.4. = Localisation des fichiers sur les volumes 


Il est nécessaire de pouvoir identifier un volume. En effet, lorsqu'un 
volume n'est pas actif il est en général rangé en armoire. Il faut donc une 
intervention manuelle pour monter/démonter un volume sur un tourne- 
disque. Cette opération est exécutée par un opérateur. Celui-ci reconnait 
un volume gráce à un numéro (ou nom) attribué à chaque volume. Pour 
pouvoir contróler les opérateurs lors des montages/démontages de 
volume et éviter les erreurs ce numéro est écrit sur le volume. 


Premier secteur d'un volume permettant d'identifier ce volume et contenant en particulier 


[rene 15 : Label de volume (Label) 
son numéro. 


Lorsqu'on a retrouvé et monté le volume supportant un fichier, il 
faut retrouver le fichier sur le volume. Pour cela, chaque fichier possède 
un ensemble d'informations descriptives (nom, adresse, début...) 
regroupées dans un descripteur du fichier. 


Ensemble des informations permettant de retrouver les caractéristiques d'un fichier, 
contenant en particulier le nom du fichier, sa localisation sur disques... 


| sen 16 : Descripteur de fichier (Directory entry) 

Il est important que l'ensemble des descripteurs de fichiers contenu 
sur un volume définisse tous les fichiers d'un volume. On obtient ainsi 
des volumes autodocumentés, donc portables d'une installation à une 
autre. Pour cela, les descripteurs de fichiers d'un volume sont regroupés 
dans une table des matières du volume. 


Notion 17 : Table des matières d'un volume (Disk pack directory) 
Table (ou fichier) située sur un volume et contenant les descripteurs des fichiers du 
volume. 
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Cette table est, soit localisée en un point conventionnel du volàme (par 
exemple, à partir du secteur 1), soit écrite dans un fichier spécial de nom 
standard, appelé catalogue du volume. Le descripteur de ce premier 
fichier peut alors être contenu dans le label du volume. En résumé, la 
figure 11.5 illustre l'organisation des informations étudiées jusqu'à pré- 
sent sur un volume. 


VOLUME n 


Y TABLE DES MATIÈRES 


LABEL n 








F11F2]F3/F4 


























Fig. I.5. — Schéma représentant l'organisation d'un volume 


Quand le nombre de fichiers d'une installation devient élevé, on est 
conduit à classer les descripteurs de fichiers dans plusieurs catalogues, 
par exemple un par usager. Les descripteurs des fichiers catalogues peu- 
vent alors étre maintenus dans un catalogue de niveau plus élevé. On 
aboutit ainsi à des catalogues hiérarchisés qui sont implantés dans de 
nombreux systèmes [Daley 65]. 


3.5. — Contrôle des fichiers 


Le noyau d'un gestionnaire de fichiers inclut également des fonc- 
tions de contróle des fichiers : partage des fichiers, résistance aux pan- 
nes, sécurité et confidentialité des données. Nous n'étudions pas ici ces 
problémes qui font l'objet de nombreux développements dans le 
contexte des bases de données, et donc dans les chapitres suivants. 
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4. ÉTUDE DES ORGANISATIONS 
ET MÉTHODES D'ACCÈS SÉLECTIVES 


4.1. — Notion de clé 


Une méthode d'accés sélective permet à partir de l'identifiant d'un 
article de déterminer l'adresse d'un article (adresse début) et de lire Parti- 
cle en moins de 5 E/S. L'identifiant d'un article est appelé clé (que l’on 
qualifie parfois de primaire). 


Notion 18 : Clé d'article (Key) 
Identificateur d'un article permettant de sélectionner un article unique dans un fichier. 


La clé peut ou non figurer comme une donnée de l'article. 


Exemple : ETUDIANT (N°, Nom, Prénom, Adresse, date d’inscrip- 
tion, résultats) est un fichier dont chaque article contient les données 
écrites entre parenthèses. La clé est N° ; c'est une donnée de l'article. A 
partir de cette clé, c'est-à-dire d'un N? d'étudiant, une méthode d'accés 
sélective doit permettre de déterminer l'adresse de l'article dans le 
fichier. 


Comme déjà dit, il existe différents types d'organisations sélectives 
(et de méthodes d'accés associées). Nous allons ci-dessous étudier les 
principales. 


4.2. — Organisation relative 


Dans cette organisation trés simple, la clé est un nombre entier 
(numéro d'article) qui permet directement de déterminer l'adresse rela- 
tive de l'article dans le fichier. 


Notion 19 : Fichier relatif ou direct (Direct file) 


Fichier d'articles de longueur fixe où chaque article possède une clé unique qui est son 
numéro d'ordre dans le fichier. 


L longueur fixe 





Fig. 11.6. — Fichier relatif 
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La figure IL.6 illustre la notion de fichier relatif. 


L'adresse relative de début d'un article de clé i se calcule alors très 
simplement par la formule : 
AR =f?x iï 


ou AR est l'adresse relative et ? la longueur des articles. Dans le cas oü les 
articles sont de longueur variable 6, f, 6, ... 8, il est possible d'utiliser un 
fichier relatif avec des articles dont la longueur est celle de l'article de 
longueur maximum. Dans ce cas on a donc : 


£ = Max (h, b, 6, ..., hy ... 6.) 
Ceci implique une perte de place qui peut être importante. 


La méthode d'accès relative présente l'avantage de simplicité : 
lorsqu'on connaît la clé d'un article, on accède à l'article en une entrée- 
sortie, Les inconvénients sont par contre nombreux. Outre le fait que les 
articles doivent être de longueur fixe ou approximativement, il faut être 
capable d'associer un numéro à chaque article et il faut conserver cette 
association dans le programme. Dans le cas où les numéros relatifs (clés) 
ne sont pas continus, le fichier est plein de trous. On a alors une perte de 
place importante. En résumé, la méthode n'est valable que pour les 
petits fichiers d'articles de taille à peu près fixe numérotés continûment. 


4.3. — Organisation aléatoire 


La clé d'un article est une donnée figurant dans l'article, Par exem- 
ple, pour un fichier d'étudiant, ce pourra être le numéro d'étudiant, où 
le numéro de sécurité sociale de l'étudiant. A partir de la clé, la méthode 
d'accés calcule l'adresse relative d'une zone appelée paquet (Bucket en 
anglais) dans lequel est placé l'article. Plus précisément, le fichier est 
divisé en p paquets de taille fixe L. Un paquet est généralement lu/écrit 
en une seule entrée-sortie. La clé permet de déterminer un numéro de 
paquet N et son adresse relative est alors obtenue par la formule : 


AR = NxL. 


Nous introduirons donc la notion de fichier aléatoire comme suit, 


Notion 20 : Fichier aléatoire (Hashed file) 
Fichier dans lequel les articles sont placés dans des paquets dont l'adresse est calculée à 
l'aide d'une fonction de hachage appliquée à la clé. 


A l'intérieur d’un paquet, les articles sont rangés à la suite dans 
l'ordre d'arrivée. Ils sont retrouvés grâce à la donnée contenant la clé. La 
figure 11.7 illustre la structure interne d'un paquet. 
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Lorsqu'un nouvel article est inséré dans un fichier, il est logé à la pre- 
miére place libre dans le paquet. S'il n'y a pas de place libre, on dit qu'il 
y a débordement. Il faut évidemment contróler l'unicité de la clé d'un 
article lors des insertions. 








Article a4 de 
longueur lga; I. 1981... | | Adresse premier octet 
^w libre dans le paquet 
á q 
x 
Article a, de 
longueur lgag = (lu _ > igaz, me 
a 
. ? L Octets 
Article az de z — —1i 
longueur |ga3 L |... lgas 724 
EN a; 
ag 
bcm N 








Fig. 11.7. — Structure interne d'un paquet 


A partir de la clé d'un article, on calcule le numéro de paquet dans 
lequel l'article est placé à l’aide d'une fonction appelée fonction de 
hachage (fig. 11.8). Une fonction de hachage doit être choisie de sorte à 
distribuer uniformément les articles dans les paquets. Plusieurs techni- 


ques sont possibles : 

— le pliage consiste à choisir et combiner des bits de la clé (par exemple 
par ou exclusif) ; 

— les conversions de la clé en nombre entier ou flottant avec utilisation 
de la mantisse permettent d'obtenir également un numéro de paquet ; 
— ]e modulo est sans doute la fonction la plus utilisée ; il consiste à 
prendre pour numéro de paquet le reste de la division de la clé par le 
nombre de paquets. 


Ces techniques peuvent éventuellement étre combinées. 


Fonction 
de hachage 


L L 4 ; L.. Leme css l A a 
o 1 2 ï n } paquets 










Clé 





Fig. 11.8. — Illustration d'un fichier aléatoire 
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À titre d'exemple, soit un fichier de 47 paquets et des articles de clé 
numérique. Le módulo 47 pourra alors être une fonction adoptée. Ainsi, 
Particle de clé 100 sera placé dans le paquet 6, l’article de clé 47 dans le 
paquet 0, celui de clé 123 dans le paquet 29, etc. 


Le probléme de débordement se pose lorsqu'un paquet est plein. 
Une premiére solution simple consiste à ne pas gérer de débordements et 
à répondre fichier saturé à l'utilisateur. Ceci implique une mauvaise utili- 
sation de la place occupée par le fichier, surtout si la distribution des arti- 
cles dans les paquets est mauvaise. Des solutions plus satisfaisantes 
consistent à utiliser une technique de débordement parmi l'une des sui- 
vantes [Knuth 73] : 


— V'adressage ouvert consiste à placer l'article qui devrait aller dans un 
paquet plein dans le premier paquet suivant ayant de la place libre ; il 
faut alors mémoriser tous les paquets dans lequel un paquet plein a 
débordé ; 

— le chafnage consiste à constituer un paquet logique par chaînage d'un 
paquet de débordement à un paquet plein ; 

— le rehachage consiste à appliquer une deuxième fonction de hachage 
lorsqu'un paquet est plein ; cette deuxiéme fonction conduit générale- 
ment à placer les articles dans des paquets de débordement. Dans tous les 
cas, la gestion de débordements dégrade les performances et complique 
la gestion des fichiers aléatoires. 


La méthode d'accés basée sur l'organisation aléatoire a plusieurs avan- 
tages. En particulier, elle s'adapte à des fichiers de clés quelconques, reste 
simple et donne d'excellentes performances tant qu'il n'y a pas de débor- 
dements. En particulier, une lecture d'article s'effectue en une entrée-sortie 
(lecture du paquet) alors qu'une écriture en nécessite en général deux (lec- 
ture puis réécriture du paquet). Cependant, les débordements dégradent 
rapidement les performances. De plus, le taux d'occupation de la mémoire 
secondaire réellement utilisé peut rester assez éloigné de 1. Enfin, la taille 
d'un fichier doit être fixée a priori. Afin de lever ce dernier inconvénient 
trés important (taille non évolutive), des techniques de hachage vir- 
tuel (encore appelées hachage dynamique ou étendu) ont été proposées 
[Litwin 78, Fagin 79, Litwin 80, Scholl 81]. 


4.4. — Principes des organisations indexées 


4.4.1. — Notion d'index 


Le principe de base des organisations et méthodes d'accàs indexées 
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est d’associer à la clé d’un article son adresse relative dans le fichier à 
l'aide d’une « table des matières » du fichier, appelée index. 


Notion 21 : Index (Index) 


Table (ou plusieurs tables) permettant d'associer à chaque clé d'article l'adresse relative de 
cet article. 


La figure II.9 illustre cette notion d'index. L'index d'un fichier peut en 
général étre rangé dans le fichier ou dans un fichier spécial. 






_— Articles 








ro 2 4 6 8 10 12 14 16 18 20 22 24 








L > Adresses relatives Index 


Fig. 11.9. = Exemple de fichier indexé 


Les étapes successives exécutées pour l'accés à un article dans un 
fichier indexé sont les suivantes : 


a) accès à l'index, 

b) recherche sur la clé de l'article désiré afin d'obtenir l'adresse relative 
de l'article ou d'un paquet contenant l'article, 

c) conversion de l'adresse relative en adresse absolue, 

d) accés à l'article (ou au paquet d'articles) sur disques magnétiques, 

e) transfert de l'article dans la zone du programme usager. 


4.4.2. — Variantes possibles 


Tout d'abord, un index d'un fichier peut être trié ou non. Le fait 
que l'index soit trié autorise la recherche dichotomique. Ainsi, un index 
contenant n clés, divisé en blocs (d'un secteur) de b clés nécessitera en 
moyenne n/2b accès pour retrouver une clé s’il n'est pas trié alors qu'il 
suffira de Log, n/b accès s'il est trié. A titre d'illustration, avec n = 105, 
b = 100 clés, on obtient 10 accès si l'index est trié contre 5 000 accès 
sinon. 


Un index d'un fichier indexé peut contenir toutes les clés (c'est-à- 
dire celles de tous les articles) ou seulement certaines. Afin de différen- 
cier les méthodes d'accés obtenues, on introduit la notion de densité 
d'un index. 
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[hn 22 : Densité d'un index (Index key selectivity) 
Quotient du nombre de clés dans l'index sur le nombre d'articles du fichier. 


La densité d'un index varie entre 0 et 1. Les cas intéressants à distinguer 
sont densité = 1 (on parle dans ce cas d'index dense) et densité < 1 où 
l'on parle d'index non dense. Dans le cas d'index non dense, les articles 
du fichier ainsi que l'index sont triés. Le fichier est divisé en paquets de 
taille fixe et chaque paquet correspond à une entrée en index contenant le 
doublet : « plus grande clé du paquet-adresse relative du paquet >. La 
figure II.10 illustre un index non dense et le fichier correspondant. 


1-3-7 i | 9-11-23 j L 2565-30-31, 
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Fig. 11.10. — Exemple d'index non dense 


Finalement, compte tenu que le fichier peut étre trié ou non trié, l'index 
dense ou non dense, trié ou non trié, diverses variantes sont théorique- 
ment possibles. Le tableau de la figure 11.11 illustre les possibilités prati- 
ques. 
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Fichier 
Trié Non trié 
F——À 
Trié Possible IS3 
1 Dense p- 
N Non trié 7 ]. Possible 
D 
is ISAM 
E Trié 
x VSAM 
Non dense pos DEAS ; 
Non trié EZ 
IS3 = Indexé type système 3 
ISAM = Séquentiel indexé IBM 
VSAM = Séquentiel indexé régulier IBM 
UFAS = Séquentiel indexé régulier CIIHB 


Fig. 11.11. — Variantes de méthodes d'accès indexées 
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4.4.3. — Index hiérarchisé et arbre balancé 


Un index peut être vu comme un fichier de clés. Il est donc possible 
de créer un index d’index, c’est-à-dire des index à plusieurs niveaux. Un 
tel index est appelé index hiérarchisé. 


Notion 23 : Index hiérarchisé (Multilevel index) 

Un index hiérarchisé à 2 niveaux est un index trié divisé en paquets, possédant lui-même 
un index, la clé de chaque entrée de ce dernier étant la plus grande du paquet. Un index 
hiérarchisé à n niveaux est un index hiérarchisé à n — 1 niveaux, possédant lui-même un 
index à un niveau. 


La figure 11.12 illustre un index hiérarchisé. La notion d'index hiérar- 
chisé est indépendante du nombre de niveaux qui peut grandir autant 
que nécessaire. 


2130 Niveau 
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Fig. 11.12. — Exemple d'index hiérarchisé 





Afin de mieux caractériser la notion d'index hiérarchisé et de la ren- 
dre indépendante des particularités d'implantation, on a été amené à 
introduire une structure d'arbre, avec un nombre variable de niveaux. 
Cette structure appelée arbre balancé (arbre-B) [Bayer 72, Comer 79] 
peut être introduite formellement comme suit : 


Notion 24 : Arbre-halancé ou arbre-B (B-tree) 

Un arbre balancé d'ordre m est un arbre où : 

1. chaque nœud contient k clés triées de gauche à droite, avec m < k < 2 m, sauf la 
racine qui contient entre 1 et 2 m clés ; 

2. un nœud est soit terminal, soit possède (k + 1) fils ; le ie fils possède des clés compri- 
ses entre la (i— 1)* et la i* clé du père ; 

3. l'arbre est équilibré, c'est-à-dire que tous les nœuds terminaux sont au méme niveau. 
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Au point 2, on considère que la clé O du père est celle du grand-père 
ayant le rang du père — 1, et que la dernière clé du père est celle du 
grand-père ayant le rang du père. Si le grand-père n'existe pas, la clé 0 est 
alors la valeur de tri initiale (aa...a) et la dernière la valeur finale (zz...z). 


La figure II.13 illustre un arbre-balancé d'ordre 1. 











Fig. 11.13. — Arbre-B d'ordre 1 


La recherche d'une clé dans un arbre-B s'effectue en partant de la 
racine. En règle générale, les valeurs contenues dans un nœud partition- 
nent les valeurs possibles de clés en un nombre d'intervalles égal au nom- 
bre de branches. Ainsi, si la valeur cherchée est inférieure à la première 
clé du nœud, on choisit la première branche ; si elle est comprise entre la 
première clé et la deuxième clé, on choisit la deuxième branche, etc. si 
une clé n'est pas trouvée après recherche dans un nœud terminal, c'est 
qu'elle n'existe pas. 


Le nombre de niveaux d'un arbre-B est déterminé par son degré et le 
nombre de clés contenues. Ainsi, dans le pire des cas si l'arbre est rempli 
au minimum, il existe : 

— une clé à la racine, 
— deux branches en partent avec m clés, 
— (m + 1) branches en partent avec m clés. 


Pour un arbre de ? niveaux, le nombre de clés est donc : 


] *2m(l- (m + 1) + (m + D? + ... + (m + 1)t-2 
= 1 + 2((m 1) ! = 1) 


D'où l'on déduit que pour stocker N clés, il faut : 





l= 1 + log, AEA niveaux. 
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Par exemple, pour stocker 1 999 999 clés avec un arbre-B de degré 99, il 
faut : 


t< Ï + logs 106 = 4 


soit, au plus quatre niveaux. Ceci conduit à penser qu'un article d'un 
fichier de deux millions d'articles avec un index hiérarchisé organisé 
comme un arbre-B peut être cherché en quatre entrées-sorties. 


L'insertion d'une clé dans un arbre-B est une opération complexe. 
Elle peut étre définie simplement de maniére récursive comme suit : 


a) rechercher le noeud terminal qui devrait contenir la clé à insérer et l'y 
insérer en bonne place ; 

b) sile nombre de clés aprés insertion de la nouvelle clé est supérieur à 
m — 1, alors migrer la clé médiane au niveau supérieur, en répétant la 
procédure d'insertion dans le nœud supérieur. 


A titre d'exemple, la figure II.14 représente les étapes nécessaires à Pin- 
sertion de la clé (tu) dans l'arbre-B représenté figure II.13. 


La suppression d'une clé souléve également des problémes. Tout 
d'abord, si l'on supprime une clé non terminale, il faut remonter la clé 
suivante pour garder le partitionnement. De plus, si un noeud a moins de 
m clés, il faut le regrouper avec le précédent de même niveau afin de res- 
pecter la définition. 


L'utilisation des arbres-B pour réaliser des fichiers à index hiérar- 
chisés peut s'effectuer de deux maniéres : 


— l'arbre balancé peut être utilisé pour réaliser seulement les index ; autre- 
ment dit, seules les clés sont stockées dans un arbre-B et les articles sont 
stockés dans un fichier classique ; une telle organisation correspond à la 
méthode IBM indexée série 3 que nous appelons IS3 ; de plus, dans cette 
méthode, toutes les clés des articles restent au niveau le plus bas de l'arbre-B. 


— l'arbre balancé peut être utilisé pour réaliser fichier et index ; autre- 
ment dit, les articles sont stockés dans l'arbre-B ; dans ce cas, seules les 
clés sont déplacées au niveau supérieur, c'est-à-dire que les articles res- 
tent au niveau le plus bas de l'arbre ; ceci correspond à l'organisation 
séquentielle indexée réguliére de IBM connue sous le nom de VSAM et 
également à celle de CIIHB connue sous le nom UFAS. 


Nous allons ci-dessous présenter ces deux organisations ainsi que 
l'organisation séquentielle indexée de IBM connue sous le nom de 
ISAM. 
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Fig. 11.14. — Insertion de la clé (tu) 


4.5. — Organisation indexée IS3 


Cette organisation est voisine de celle des systémes 3,38... de IBM. 
Les articles sont rangés en séquentiel dans un fichier dont l'index est 
dense et organisé sous forme d'un arbre-B. 


Notion 25 : Fichier indexé (Indexed file) 
Fichier non trié, d'index trié dense organisé sous forme d'un arbre-B. 


L'interprétation de la définition que constitue la notion 25 souléve 
plusieurs problémes. Tout d'abord, comment est défini l'ordre de 
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l'arbre-B qui constitue l'index ? La solution consiste à diviser l'index en 
pages (une page = 1 à p secteurs). Lors de la première écriture, les pages 
ne sont pas complètement remplies. Lors d'une insertion, si une page est 
pleine, elle est éclatée en deux pages à demi-pleines. La clé médiane est 
remontée au niveau supérieur. ` 


Un deuxième problème consiste à garder un index dense. En fait, 
celui-ci est dense au dernier niveau. Autrement dit, toutes les clés d'arti- 
cles sont gardées au plus bas niveau. Ainsi, quand une page éclate, la clé 
médiane devient la plus grande clé de la première page résultant de l'écla- 
tement. Cette clé est donc dupliquée au niveau supérieur de l'index. La 
figure II.15 illustre une insertion dans un fichier indexé 


Un dernier probléme est celui du stockage de l'index. Celui-ci peut 
être stocké en fin de fichier. Il est ainsi possible de lire la page supérieure 
de l’index en mémoire centrale lors du début d’un travail sur un fichier, 
puis de la réécrire en fin de travail. Il est aussi possible avec une telle 
méthode d’enregistrement des index de garder les versions historiques 
des index à condition que les nouveaux articles écrits le soient après le 
dernier index enregistré, c'est-à-dire en fin de fichier. 


La méthode d'accés-organisation indexé 1S3 présente plusieurs 
avantages : l'insertion des articles est simple puisqu'elle s'effectue en 


(a) Etat avant insertion de (7) Fichier 
12 5 15 








(b) Etat aprés insertion de (7) 1 12 5 15 7 


7 e - 
18 + 
12 


La clé 15 est 
reportée pour 
permettre une 
meilleure optimisation. 




















B 


15 





Fig. 11.15. — /nsertion dans un fichier IS3 
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séquentiel dans le fichier ; il est possible de garder des versions histori- 
ques des index. Les performances de la méthode sont satisfaisantes. Si m 
est le nombre de: clés par page d'index, du fait de l'organisation de 
l'index en arbre-B, le nombre d'entrées-sorties nécessaires pour lire un 
article dans un fichier de N articles reste inférieur ou égal à : 


N +1 
2 + logima ^ 


Une écriture nécessite en général deux accès, sauf dans les cas d'éclate- 
ment de page index où il faut une lecture et deux écritures de plus par 
niveau éclaté, en général. En pratique, et à titre d’exemple, un fichier de 
moins de 10° articles ne nécessitera pas plus de trois entrées-sorties en lec- 
ture. 


Cette méthode présente cependant trois inconvénients sérieux : 
— du fait de la séparation des articles et de l'index les mouvements de 
bras des disques sont en général importants ; 
— la lecture en séquentiel par clé croissante doit se faire par consul- 
tation de l'index et est en conséquence trés coüteuse ; 
— l'index est dense et donc de grande taille si aucune technique de com- 
pactage de clés n'est mise en œuvre. 


4.6, — Organisation séquentielle indexée ISAM 


4.6.1. — Présentation générale 


Il s'agit de l'organisation IBM utilisée dans les systémes DOS, 
OS/VS et connue sous le nom ISAM (Indexed Sequential Access 
Method) [IBM 78]. 


Notion 26 : Fichier séquentiel indexé (Indexed sequential file) 

Fichier trié d'index trié non dense composé d'une zone primaire et d'une zone de déborde- 
ment. Une piste saturée déborde dans une extension logique constituée par une liste 
d'articles en débordement. 


Un fichier ISAM comporte trois zones logiques : 
— zone primaire où l’on écrit les articles à la première écriture, 
— zone de débordement où l’on transfère les articles lors des‘additions 


au fichier, 
— zone d’index où l’on écrit les index. 


Ci-dessous nous étudions successivement chacune des zones. 
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4.6.2. — Etude de la zone primaire 


La zone primaire se compose de cylindres successifs dont certaines 
pistes sont réservées pour les index et les zones de débordement. En zone 
primaire, les articles sont enregistrés par ordre croissant des clés. Ils peu- 
vent être bloqués ou non. Lors de la première écriture du fichier, les arti- 
cles doivent être délivrés au système de fichiers par ordre croissant des 
clés. La figure IT.16 illustre un fichier ISAM après une première écriture. 
Ce fichier est composé de deux cylindres. 


Z Z, Pistes d'index 
1 


























3 5,7 21,23 , 27 
9 ,14 ,17 29 31, 
Pistes de 
débordement 
Cylindre O Cylindre 1 


Fig. 11.16. — Fichier ISAM après une première écriture des articles 1,8,5,7,9,14,17,21, 
23,27,29,31 (dans l'ordre) 


4.6.3. — Etude de la zone de débordement 


Il existe deux types de zone de débordement : la zone de déborde- 
ment de cylindres composée de quelques pistes sur chaque cylindre et la 
zone de débordement indépendante, composée des derniers cylindres du 
fichier (fig. II.17). 








` ae > trr 
Ë, Zone de débordement 
j de cylindre Zone de débordement 
indépendante 


Fig. 11.17. — Zones de débordement d'un fichier ISAM 


En zone de débordement, les articles ne sont pas bloqués. Ils sont 
chaînés entre eux afin de reconstituer la piste qui a débordé de manière 
logique. Quand un article est inséré, on recherche sa séquence dans la 
piste logique. S'il est placé en zone primaire, les articles suivants sont 
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déplacés et le dernier est écrit en zone de débordement. Les chainages 
sont mis à jour. S'il vient en zone de débordement, il est écrit dans cette 
zone et inséré en bonne place dans la chaîne des articles en débordement. 


La zone de débordement de cylindre est tout d'abord utilisée. 
Lorsqu'elle est saturée, la zone de débordement indépendante est utili- 
sée. Dans ce cas, du fait que le chaînage est effectué par ordre croissant 
des clés, il est possible que celui-ci parte de la zone de débordement de 
cylindre, puis pointe en zone de débordement indépendante, puis 
revienne en zone de débordement de cylindre, etc. Dans ce cas, la 
méthode devient particuliérement peu performante pour rechercher un 
article dans une piste ayant débordé, du fait des déplacements de bras. 


4.6.4. — Etude de la zone index 


Il existe obligatoirement deux niveaux d'index et optionnellement 
trois : les index de pistes, les index de cylindres et le (ou les) index maî- 
tres, 


Le premier niveau d'index obligatoire est l'index de piste. Il en 
existe un par cylindre : il est en général contenu sur la premiére piste du 
cylindre. Chaque entrée correspond à une piste du cylindre : elle fournit 
Ia plus grande clé de la piste en zone primaire, son adresse de début, la 
plus grande clé de la piste logique en zone de débordement ainsi que 
l'adresse du premier article en zone de débordement s'il existe. La figure 
II.18 illustre le format de l'index de piste. 


c] [wm — [T 1. Cc [Fer Fes 


Entrée piste O Entrée piste 1 Entrée piste n 
CD = Contrôle de débordement précisant l'adresse du dernier article de la zone de 
débordement. 


PCP = Plus grande clé en zone primaire et adresse de la piste. 
PCD = Plus grande clé en zone de débordement et adresse du premier article en zone 
de débordement. 


Fig. 11.18. — Format de l'index de piste 


Le deuxième niveau d’index obligatoire est l’index de cylindre. Il 
existe un index de cylindre par fichier. Cet index contient une entrée par 
cylindre comportant la plus grande clé du cylindre ainsi que l’adresse du 
cylindre. L'index de cylindre est généralement rangé dans une zone parti- 
culière, par exemple en début de zone de débordement indépendante. 
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Cet index permet, à partir d’une clé d’article, de sélectionner le cylindre 
où doit se trouver l'article. 


Le troisième niveau d'index est optionnel : c'est l'index maitre. Il 
est utilisé quand l'index de cylindre est trop grand afin d'accélérer les 
recherches. Il existe une entrée en index maître par piste de l'index de 
cylindre. Cette entrée contient l'adresse de la piste et la valeur de la plus 
grande clé dans la piste. 


4.6.5. — Vue d'ensemble 


La figure I1.19 donne une vue d'ensemble d'un fichier ISAM aprés 
insertion d'articles, avec seulement deux niveaux d'index. Les avantages 
de la méthode sont le fait que le fichier est trié, ce qui facilite l'accés en 
séquentiel trié, ainsi que les temps d'accés tant que le fichier n'a pas 
débordé (3 E/S pour lire un article). Les inconvénients sont, d'une part, 
la gestion des débordements qui est complexe et dégrade les performán- 
ces de sorte qu'il est nécessaire de réorganiser périodiquement les fichiers 
ayant débordé, et d'autre part le fait que la méthode d'accés ne soit pas 
indépendante des caractéristiques physiques du support (pistes, cylin- 
dres...). Les performances dépendent des débordements. Si une piste 
comporte d articles en débordement, une lecture nécessitera approxima- 
tivement 3 + [d/2] entrées-sorties alors qu'une écriture demandera 2 + 
[d/2] + 4 entrées-sorties, ceci afin de trouver la position de l’article, 
l'écrire et mettre à jour les chaînages. Ceci peut devenir très coûteux. 
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Fig. 11.19. — Vue d'ensemble d'un fichier ISAM 
(Les pointeurs issus du cylindre 1 ne sont pas représentés) 
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4.7. — Organisation séquentielle indexée régulière VSAM 


4.7.1. — Présentation générale 


Il s’agit de l’organisation IBM utilisée dans le système IBM OS/VS 
et connue sous le nom de VSAM (Virtual Sequential Access Method) 
[IBM 78]. 

Notion 27 : Fichier séquentiel indexé régulier (Virtual sequential file) 
Fichier trié d'index trié non dense dont l'ensemble fichier plus index est organisé sous 
forme d'un arbre-B. 


Le fichier est divisé en aires, une aire étant un ensemble de pistes du 
même cylindre ou de cylindres contigus. Chaque aire est elle-même divi- 
sée en intervalles, un intervalle étant généralement composé d'une partie 
de piste ou de plusieurs pistes consécutives lue(s) en une seule entrée- 
sortie. Lorsqu'un intervalle est saturé, il éclate en deux intervalles ; 
lorsqu'une aire est saturée, elle éclate aussi en deux aires, si bien que le 
fichier se réorganise de lui-méme par incréments. 


Cette organisation résulte d'une étude critique de ISAM. Cette fois, 
le fichier est plus indépendant de la mémoire secondaire : la piste est 
remplacée par l'intervalle qui peut être une fraction de piste ou plusieurs 
pistes, le cylindre est remplacé par la notion d'aire. Les débordements ne 
perturbent plus l'organisation puisque le mécanisme de débordement est 
celui de l'arbre-B, c'est-à-dire qu'un intervalle ou une aire saturée écla- 
tent en deux. 


4.7.2. — Etude de la zone des données 


Cette zone qui contient les articles est divisée en intervalles et aires, 
comme représentée figure II.20. Lors de la premiére écriture, comme 
avec des fichiers séquentiels indexés ISAM, les articles sont enregistrés 
triés, c'est-à-dire que le programme doit les délivrer à la méthode d'accés 
dans l'ordre croissant des clés. Cette fois, les mises à jour sont prévues : 
de la place libre est laissée dans chaque intervalle et des intervalles libres 
sont laissés dans chaque aire afin de permettre les insertions de nouveaux 
articles. : 


A titre d'exemple, le fichier de la figure II.20 a été créé avec les deux 
paramétres suivants : 


— % octets libres par intervalles = 25 ; 
— % intervalles libres par aire = 25. 


'Lors de la premiére écriture, le programme créant le fichier a délivré au 
"système les articles suivants (dans l'ordre) : 1,5,7,9,15,20,22 27,30,31, 
33,37,40,43,47,51,53. 





| 
| 
| 
i 
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Zone index 
























































Aire O Aire 1 
composée de quatre intervalles composée de quatre intervalles 


Fig. 11.20. — Fichier séquentiel indexé régulier après la première écriture 


L'algorithme d'insertion d'un article consiste à déterminer grâce 

aux index l'intervalle qui doit contenir l'article. Ensuite, deux cas sont 
possibles : 
à). si l'intervalle n'est pas plein,alors l'article est rangé dans l'intervalle, 
en bonne place dans l'ordre lexicographique des clés. Par exemple, 
l'insertion de l'article de clé 10 conduira à la substitution d'intervalle 
représentée figure II.21 ; 


Insertion de 10 
[20] 


Fig. 11.21. = Insertion de l'article de clé 10 dans le fichier représenté figure 11.20 





b) si l'intervalle est plein, alors il éclate en deux intervalles à demi-pleins. 
Deux cas sont encore possibles : 

bl) s'il existe.un._intervalle-libre-dans-l'aire, celui-ci est utilisé afin 
de stocker l'un des deux intervalles résultant de l'éclatement. Par exem- 
ple, l'insertion de l'article de clé 13 dans le fichier obtenu après insertion 
de l'article de clé 10 (fig. II.21) conduit au fichier représenté figure II.22. 

b2) s'il n'existe pas-d^intervalle libre dans l'aire, on alloue alors une 
aire vide au fichier et on éclate l'aire saturée en deux à demi-pleines ; 
pour cela la moitié des intervalles contenant les articles de plus grandes 
clés sont recopiés dans l'aire nouvelle. Par exemple, l'insertion des arti- 
cles de clés 11 et 12 dans le fichier de la figure IL.22 conduit au fichier 
représenté figure II.23. 
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Zone index 


Zone index 
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Aire 0 Aire 1 
Fig. 11.22. — Fichier après insertion des articles de clés 10 et 13 | 
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Fig. 11.23. — Fichier aprés insertion des articles supplémentaires 11 et 12 
| 4.7.3. — Etude de la zone index 


| appelé index d'intervalles. Il en existe un par aire. Chaque entrée 
| contient la plus grande clé de l'intervalle correspondant ainsi que son 
| adresse. Le deuxiéme niveau est appelé index d'aires. Il en existe un par 
| fichier. Chaque entrée contient la plus grande clé de l'aire correspon- 
| dante ainsi que l'adresse de l'aire. Il est également possible, dans le cas | 


| 

| 

| 

* ` ` n ` | 

| Il peut exister deux ou trois niveaux d'index. Le premier niveau est | 
| 
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| 
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où l'index d'aire est trop grand (par exemple plus d’une piste), de faire 
gérer au systéme un index de troisiéme niveau appelé index maftre et per- 
mettant d'accéder directement à la partie pertinente de l'index d'aire. A 
titre d'illustration, la figure I1.24 représente les index d'intervalles et 
d'aires du fichier représenté figure 11.23. 

















7.0 |11.1]13.2 37.0] 47.1|53.2 
Index d'intervalles Index d'intervalles 
aire O aire 1 

20.0| 30.1 





Index d'intervalles 
aire 2 





Index d'aires 


Fig. 11.24. — Index du fichier représenté figure 11.23 


4.7.4. — Vue d'ensemble 


La figure 11.25 donne une vue d'ensemble d'un autre fichier VSAM 
composé de deux aires, avec seulement deux niveaux d'index. Les avan- 
tages de la méthode sont le fait que le fichier est trié, ce qui facilite les 
accès en séquentiel trié, ainsi que les temps d’accès à un article : la lec- 
ture s'effectue toujours en trois entrées-sorties. Les inconvénients sont 
peu nombreux ; cependant l'écriture peut parfois être trés longue dans le 
cas d'éclatement d'intervalles ou pire, dans le cas d'éclatement d'aires. 
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5. CONCLUSION 


Nous venons de passer en revue les fonctions essentielles et les tech- 
niques de base des gestionnaires de fichiers. D'autres études peuvent être 
trouvées dans [Gardarin 79, Jouffroy 77, Widerhold 77]. 1l faut savoir 
qu'un service de gestions de fichiers est de plus en plus souvent la base 
d'un systéme de gestion de bases de données. Pour ce faire, des niveaux 
supérieurs de logiciels sont généralement implantés pour assurer la ges- 
tion d'index multiples, la description centralisée des données des articles 
de fichiers, des interfaces de gestion de données variées avec les program- 
mes d'applications, etc. 


La nécessité de pouvoir supporter un Systéme de Gestion de Bases 
de Données tend aujourd'hui à compliquer le service de gestion de 
fichiers qui devient de plus en plus élaboré. Il n'est par exemple pas rare 
de trouver des systémes gérant plusieurs index sur des clés différentes 
pour un méme fichier. En effet, les Systémes de Gestion de Bases de 
Données, pour permettre la consultation des données selon des critéres 
variés, nécessitent généralement plusieurs chemins d'accés à un méme 
article. 
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Ill. OBJECTIFS ET ARCHITECTURES 
DES SYSTÈMES DE GESTION 
DE BASES DE DONNÉES 


1. INTRODUCTION 


Même s'ils n'ont jamais utilisé de système de gestion de bases de 
données (SGBD), la plupart des lecteurs ont une idée de ce qu'est une 
base de données (BD) et par là-méme un SGBD. Une BD est peut-étre 
pour certains une collection de fichiers reliés par des pointeurs en tout 
sens, aussi cohérents entre eux que possible, organisés de manière à 
répondre efficacement à une grande variété de besoins. Pour d'autres, 
elle peut aussi apparaitre comme une collection d'informations modéli- 
sant une entreprise. Ainsi, un SGBD peut donc à la fois apparaitre comme 
un ensemble de logiciels et matériels associés permettant de gérer un ensem- 
ble de fichiers interdépendants ou permettant de modéliser une partie du 
monde réel. 


Qu'en est-il exactement ? L'objectif de ce chapitre est justement 
d'essayer de clarifier cette notion plus ou moins floue qu'est celle de 
SGBD. Pour cela, nous introduisons tout d'abord les objectifs que cher- 
chent à atteindre les SGBD. Bien sür, peu d'entre-eux satisfont pleine- 
ment tous les objectifs, mais ils y tendent tous plus ou moins. Ensuite, 
nous présentons les méthodes et concepts de base nécessaires à la com- 
préhension générale du fonctionnement des SGBD. Puis, l'architecture 
de référence proposée par le groupe de normalisation ANSI/X3/. SPARC 
est introduite. Une bonne compréhension de cette architecture est, 
comme nous le verrons dans la suite, essentielle à la compréhension des 
SGBD proposés jusqu'à ce jour. Enfin, diverses architectures de Systé- 
mes opérationnels sont étudiées. 
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2. OBJECTIFS 


Les objectifs principaux des systèmes de gestion de bases de données 
sont résumés dans la figure III.1. 





indépendance physique 

indépendance logique 

manipulation des données par des non informaticiens 
efficacité des accés aux données 

administration centralisée des données 

non redondance des données 

cohérence des données 

partageabilité des données 

sécurité des données 











Fig. 111.1. — Objectifs des SGBD 


Dans la pratique, ces objectifs ne sont que trés partiellement 
atteints. Ci-dessous nous examinons successivement chacun d'eux. 


2.1. — Indépendance physique 


Une donnée élémentaire décrit un événement atomique du monde 
réel. Par exemple, 10 000 F est une donnée élémentaire. Les groupes de 
données élémentaires qui circulent dans le monde réel ont un sens indé- 
pendamment du monde informatique. Plus précisément, il existe des 
relations intrinsèques entre données élémentaires et des règles de contró- 
les pertinentes pour employer ces données. 


Bien souvent, les données élémentaires du monde réel sont assem- 
blées pour décrire les entités et les associations entre entités directement 
perceptibles dans le monde réel. Bien que deux groupes de travail assem- 
blent généralement différemment des données élémentaires, il est possi- 
ble au sein d'une entreprise bien organisée de définir une structure cano- 
nique des données, c’est-à-dire un partitionnement particulier en ensem- 
bles et sous-ensembles ayant des propriétés bien définies et cohérentes 
avec les vues particulières. Cet assemblage peut être vu comme l'intégra- 
tion des vues particuliéres de chaque groupe de travail. Il obéit à des 
régles qui traduisent l'essentiel des propriétés des données élémentaires 
dans le monde réel. 
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Par opposition, la structure de stockage des données appartient au 
monde des informaticiens et n’a donc un sens que dans l’univers du 
système informatique. Il s'agit d'un assemblage particulier des données 
en articles, fichiers, chemins d'accès (organisations et méthodes d'accès 
des fichiers, modes de placement des articles dans les fichiers, critéres de 
tris, chainages...) sur des mémoires secondaires. Cet assemblage propre 
au monde informatique doit étre basé sur des considérations de perfor- 
mances et de souplesse d'accés. 


Un des objectifs essentiels des SGBD est donc de permettre de réali- 
ser l'indépendance des structures de stockage aux structures de données 
du monde réel [Stonebraker 74]. Il s'agit donc de pouvoir définir 
l'assemblage des données élémentaires entre elles dans le système infor- 
matique indépendamment de l’assemblage réalisé dans le monde réel, en 
tenant compte seulement des critéres de performances et de flexibilité 
d'accés. 


Les avantages de ce type d'indépendance appelée indépendance 
physique peuvent étre facilement compris si l'on considére les inconvé- 
nients de la non-indépendance physique. Celle-ci impliquerait que la 
maniére dont les données sont organisées sur mémoire secondaire soit 
directement l'image de l'organisation canonique des données dans le 
monde réel. Pour permettre de conserver les possibilités d'optimisation 
de performances vitales aux systémes informatiques, les notions de 
méthodes d'accés, modes de placement, critéres de tris, chaînages, coda- 
Bes de données devraient directement apparaitre dans le monde rée] et 
par contrecoup dans les applications. Tout changement informatique 
devrait alors étre répercuté dans la vie d'une entreprise et par contrecoup 
impliquerait une reconstruction des applications. Ceci est bien sür 
impraticable, d’où la nécessité d'indépendance des structures de stocka- 
ges aux données du monde réel. 


2.2. — Indépendance logique 


Nous avons ci-dessus admis l'existence d'une structure canonique 
décrivant complétement la sémantique inhérente aux données dans le 
monde réel. Cette structure est une Synthése des vues particuliéres de 
chaque groupe de travail. En conséquence, chaque groupe de travail réa- 
lisant une application doit pouvoir assembler différemment les données 
pour former des entités et des associations. De.pius, chacun doit pouvoir 
se concentrer sur les éléments constituant son centre d'intérêt, c'est-à- 
dire que chacun doit pouvoir ne connaitre qu'une partie de la sémanti- 
que des données et ne voir qu'une partie des données. 
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Par exemple, à partir des assemblages de données : 


VÉHICULE (N° VEH, MARQUE, TYPE, COULEUR) 
PERSONNE (N° SS, NOM, PRÉNOM) 
PROPRIÉTAIRE (N° SS, N? VEH, DATE-ACHAT) 


un groupe pourra voir des personnes possédant des voitures, c'est-à-dire 
un assemblage du type : 


PERSONNE (N° SS, PRÉNOM, NOM, N° VOITURE) 


alors qu'un autre ne verra simplement que des véhicules vendus à une 
certaine date, c'est-à-dire un assemblage du type : 


VOITURE (N° VOITURE, TYPE, MARQUE, DATE VENTE) 


Il est donc souhaitable de permettre une certaine indépendance des 
données vues par les applications à la structure canonique des données 
dans l’entreprise. Les avantages de ce type d'indépendance souvent 
appelée indépendance logique [Date 71] sont les suivants : 


— permettre à chaque groupe de travail de voir les données comme il le 
souhaite, 

— permettre l'évolution de la vue de chaque groupe de travail et de la 
vue canonique de l'entreprise sans remettre en question, au moins dans 
une certaine mesure, la vue particuliére de chaque groupe de travail ; 
ainsi il doit être possible d'ajouter des ensembles de données élémentai- 
res, d'en supprimer d'autres, d'ajouter et supprimer des ensembles 
d'associations, de redéfinir les assemblages... dans des vues particulières 
mais aussi dans la vue canonique des données sans modifier la plus 
grande partie des applications. 


2.3. — Manipulation des données par des non-informaticiens 


Du fait que les non-informaticiens voient les données, ils doivent 
pouvoir les manipuler, c’est-à-dire les interroger et les mettre à jour. Plus 
précisément, si les objectifs 1 et 2 sont atteints, les groupes de non- 
informaticiens verront les données indépendamment de leur implanta- 
tion en machine. De ce fait, ils devront pouvoir manipuler les données au 
moyen de langages non procéduraux, c'est-à-dire en décrivant les don- 
nées qu'ils souhaitent retrouver (voire mettre à jour) sans décrire la 
manière de les retrouver (voire de les mettre à jour) qui est propre à la 
machine. 
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2.4. — Efficacité des accès aux données 


Cet objectif a deux aspects. Tout d'abord, si l'on considère que cer- 
tains accès aux données sont effectués par des informaticiens avertis, 
voire des programmeurs-systèmes, connaissant la structure de stockage 
des données, il doit être possible de fournir des langages de manipulation 
de données très efficaces permettant d'accéder rapidement aux données 
le long des chemins d'accès définis dans la structure de stockage. Ces lan- 
gages doivent être utilisables à partir de programmes classiques écrits en 
assembleur ou en langages de plus haut niveau, tels COBOL, PL1 ou 


PASCAL... 


D'un autre côté, pour les non-informaticiens ainsi que pour les 
informaticiens ignorant la structure de stockage, il doit être possible 
d'utiliser un langage non procédural dont l'implantation doit être très 
efficace, notamment au niveau des accès-disques qui restent le goulot 
d'étranglement essentiel des SGBD. 


2.5. — Administration cohérente des données 


Des fonctions essentielles des SGBD sont la définition des structu- 
res de stockage et structures de données et le suivi de leurs évolutions. 
Ces fonctions sont appelées administration des données. Afin de permettre 
un contrôle efficace des données, de résoudre les conflits entre divers points 
de vue pas toujours cohérents, de pouvoir optimiser les accès aux don- 
nées et l'utilisation des moyens informatiques, il est essentiel de répartir 
ces fonctions entre les mains d'un petit groupe de personnes hautement 
qualifiées. L'administration des données est ainsi souvent centralisée. L'ob- 
jectif est seulement de permettre une administration cohérente et efficace 
des données. 


2.6. — Non redondance des données 


Dans les systèmes classiques à fichiers non intégrés, chaque applica- 
tion possède ses données propres. Ceci conduit généralement à de nom- 
breuses duplications de données avec, outre la perte de place en mémoire 
secondaire associée, un gâchis important en moyens humains pour saisir 
et maintenir à jour plusieurs fois les mémes données. 


Avec une approche base de données, les fichiers plus ou moins redon- 
dants sont intégrés en un seul fichier partagé par les diverses applications. 
L'administration cohérente des données doit veiller à la non-duplication 
physique des données afin d'éviter les mises à jour multiples. 
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2.7. — Cohérence des données 


Bien que les redondances entre données soient évitées par l'objectif 
précédent, les données sont soumises à certaines régles, soit au niveau de 
la donnée élémentaire, soit au niveau d'ensemble de données où il peut 
exister certaines dépendances entre données. Par exemple, un salaire 
peut étre compris entre 4 000 F et 100 000 F. Autre exemple, une donnée 
représentant le nombre de commandes d'un client doit correspondre au 
nombre de commandes dans la base. Un systéme de gestion de base de 
données doit donc veiller à ce que les applications respectent ces régles 
lors des modifications des données et doit ainsi assurer la cohérence des 
données. 


2.8. — Partageabilité des données 


Cet objectif est de permettre aux applications de partager les don- 
nées de la base dans le temps mais aussi simultanément. Une application 
doit pouvoir accéder aux données comme si elle était seule à les utiliser, 
sans attendre mais aussi sans savoir qu'une autre application peut les modi- 
fier concurremment. 


2.9. — Sécurité des données 


Les données doivent étre protégées contre les accés non autorisés ou 
mal intentionnés. Il doit exister des mécanismes adéquats pour autoriser, 
contróler ou enlever les droits d'accés de n'importe quel usager à tout 
ensemble de données. Les droits d'accés peuvent également dépendre de 
la valeur de données ou des accés précédemment effectués par l'usager. 


Par exemple, un employé pourra connaitre les salaires des personnes 
qu'il dirige, mais pas des autres employés de l'entreprise... 


3. CONCEPTS ET MÉTHODES DE BASE 


3.1. — Description des données 


3.1.1. — Notions de base 


Dés 1965, l'idée de décrire les données des applications de manière 
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indépendante des traitements est apparue. Plusieurs niveaux de descrip- 
tion permettent d'assurer les objectifs 1 et 2 : 

* indépendance structure de stockage et structure de données 

* jndépendance applications et structures de données. 


La séparation de la description des données des programmes d'applica- 
tions permet d'assurer l'objectif 5 : 
* administration centralisée des données. 


Toute description de données consiste à définir les propriétés 
d'ensembles d'objets modélisés dans Ja base de données, et non pas 
d'objets particuliers. Les objets particuliers sont définis par les program- 
mes d'applications lors des insertions et mises à jour de données. Ils doi- 
vent alors vérifier les propriétés des ensembles auxquels ils appartien- 
nent. On distingue ainsi deux notions essentielles : 


Notion 1 : Type d'objets (Object type) 
Ensemble d'objets possédant des caractéristiques similaires et manipulables par des opé- 
rations identiques. 


Exemples : 
1. Le type d'objet Entier 
(0, + 1,... + N,... + œj muni des opérations {+, x, /, =J] 


2. Le type d'objets Voiture composé des attributs suivants : 


VOITURE (N° VEH., MARQUE, TYPE, COULEUR) 


peut étre muni des opérations CRÉER, DÉTRUIRE, MODIFIER, 
CONSULTER qui sont des opérations standards sur un objet. 


Notion 2 : Occurrence d'objet (Object occurrence) 
Elément d'un ensemble d'objets. 


Exemples : 


1. L'entier 10 
2. La voiture (872 RH 94, CITROEN, VISA, BLEUE) 


Toute description de données s'effectue donc au niveau du type à 
l'aide d'un ensemble d'éléments descriptifs permettant d'exprimer les 
propriétés d'ensembles d'objets et composant un modèle de description 
de données. 

Notion 3 : Modèle de description de données (Data model) 
Ensemble de concepts et de règles de composition de ces concepts permettant de décrire 
des données. 


| 
i 
| 
i 
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Un modèle de description de données est souvent représenté par un 
formalisme graphique. Il est mis en œuvre à l’aide d’un langage de des- 
cription de données. 


Langage supportant un modèle et permettant de décrire les données d'une base de don- 


[ares 4 : Langage de description de données (Data description language) 
nées d'une manière assimilable par une machine. 


La description d’un ensemble de données particulier, correspondant 
par exemple à une application, à l’aide d’un langage de description 
donne naissance à un schéma. 


Notion 5 : Schéma (Schema) 
Description au moyen d'un langage déterminé d'un ensemble de données particulier. 


On distingue généralement le schéma source écrit par le groupe 
d'administration des données et le schéma objet résultant de la compila- 
tion du précédent par une machine. Le schéma objet est directement uti- 
lisable par le systéme de gestion de bases de données afin de retrouver et 
vérifier les propriétés des occurrences d'objets manipulées par les pro- 
grammes d'applications. 


3.1.2. — Niveaux de description 


Pour assurer les objectifs (1) et (2), trois niveaux de description de 
données ont été distingués par le groupe ANSI/X3/SPARC [Ansi 75, 
Tsichritzis 78]. Ils sont généralement mélangés en deux niveaux dans 
beaucoup de systémes existants. Cependant, certains systémes futurs en 
construction depuis 1976 pourraient comporter ces trois niveaux. 


Le niveau central est le niveau conceptuel. Il correspond à la struc- 
ture canonique des données qui existent dans l'entreprise, c'est-à-dire 
leur structure sémantique inhérente sans souci d'implantation en 
machine, représentant la vue intégrée de tous les groupes de travail. Par 
exemple, le schéma conceptuel permettra de définir : 


— les types de données élémentaires qui définissent les attributs des 
objets de l'entreprise (exemple : numéro de véhicule, couleur...) ; 

— les types de données composées qui permettent de regrouper les attri- 
buts afin de décrire les entités du monde réel (exemple : voiture, per- 
sonne...) ; 

— les types de données composés qui permettent de regrouper les attri- 
buts afin de décrire les associations du monde réel (exemple : proprié- 
taire...) ; 





| 
| 
| 
| 
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— éventuellement, des régles que devront suivre les données au cours de 
leur vie dans l'entreprise (exemple : l’âge d'une personne est compris 
entre 0 et 150, toute voiture doit avoir un propriétaire...). 


Un exemple de schéma conceptuel défini à l’aide du modèle entité- 
association [Chen 76] est représenté figure III.2. Un cercle représente un 
type d'attribut, un rectangle un type d'entité et un losange un type d'as- 


sociation. 
VÉHICULE ÉROPRIÉTAIRE> PERSONNE 









Fig. 11.2. — Exemple de schéma conceptuel 


Le niveau interne correspond à la structure de stockage supportant 
les données. Il permet donc de décrire ies données telles qu'elles sont 
stockées dans la machine, par exemple : 


— les fichiers qui les contiennent (nom, organisation, localisation...) ; 
— les articles de ces fichiers (longueur, champs composants, modes de 
placement en fichiers...) ; 

— les chemins d'accès à ces articles (index, chaînages, fichiers 
inversés...). 





INDEX PRIMAIRE N? VEH. 














MARQUE ADN Lau 
TYPE 
COULEUR 
DATE 
NEUSS INDEX SECONDAIRE N° $S 
Fig. 111.3. — Exemple de structure [vem 
interne | NOM 
adresse véhicule PRENOM 9APV 


adresse premier véhicule — i 7787 74 
adresse véhicule suivant = LO Zu — d 


Dbd 
uo 


V 
V 
s 


Wa 
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Par exemple, une implantation possible des données représentées 
figure IIL.2 est illustrée au niveau des types figure IIL.3. Il existe un 
fichier unique indexé sur N° VEH dont chaque article contient successi- 
vement N° VEH, MARQUE, TYPE, COULEUR, DATE de l'achat du 
véhicule, N? SS du propriétaire, NOM du propriétaire, PRÉNOM du 
propriétaire. On peut également accéder à ce fichier par un index secon- 
daire sur N? SS permettant de retrouver les véhicules d'un propriétaire 
dont on connaît le N° SS. Ces véhicules sont d’ailleurs chainés entre eux 
à partir d'une entrée figurant dans l'index secondaire. 


Au niveau externe, chaque groupe de travail utilisant des données 
possède une description des données perçues effectuée de la manière 
dont il les voit dans ses programmes d’application. Alors qu’au niveau 
conceptuel et interne, les schémas décrivent toute une base de données, 
au niveau externe ils décrivent simplement la partie des données présen- 
tant un intérêt pour un utilisateur ou un groupe d'utilisateurs. En consé- 
quence, un schéma externe est souvent qualifié de vue externe. Le 
modèle externe utilisé est souvent dépendant du langage de manipulation 
de la base de données utilisé. La figure 111.4 donne deux exemples de 
schéma externe pour la base de données dont le schéma conceptuel est 
représenté figure III.2. Il est à souligner que la notion de schéma externe 
permet d'assurer en plus de l'objectif 2 une partie de l'objectif 9 : un 
groupe de travail ne peut en effet qu'accéder aux données décrites dans 
son schéma externe. Les autres données sont ainsi protégées contre les 
accés non autorisés ou mal intentionnés de la part de ce groupe de tra- 
vail. 


Schéma externe n* 1: Schéma externe n° 2: 


VOITURE 


Fig. Ill.4. — Exemples de schémas externes 





PERSONNE 


Finalement, il est à souligner que pour une base particuliére, il existe 
un seul schéma interne et un seul schéma conceptuel. Il existe par contre, 
en général, plusieurs schémas externes. Un schéma externe peut être 
défini pour un groupe d'utilisateurs. A partir de là, il est possible de 
construire des schémas externes pour des sous-groupes du groupe d'utili- 
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sateurs considérés. Ainsi, certains schémas externes peuvent être déduits 
les uns des autres. La figure III.5 illustre les différents schémas d'une 


base de données centralisée. 


SCHÉMAS 
EXTERNES 
(K modèles) 





1 modèle unique 





SCHÉMA CONCEPTUEL 





1 modèle unique 


Fig. 111.5. — Différents schémas d'une base de données 


3.2. — Transformation des données 


Du fait qu'il peut exister plusieurs niveaux de schémas gérés par un 
systéme pour décrire un méme ensemble de données, un systéme de ges- 
tion de bases de données doit pouvoir assurer le passage des données 
depuis le format correspondant à un niveau dans le format correspon- 
dant à un autre niveau. Cette fonction est appelée transformation de 
données. 


Fonction effectuant la restructuration d'occurrences de données conformes à un schéma 


| B : Transformation de données (Data mapping) 
en occurrences de données conformes à un autre schéma. 


Dans un SGBD à trois niveaux de schémas, il existera donc deux 
niveaux de transformation : 
— la transformation conceptuelle/interne permettant de faire passer des 
occurrences de données depuis le format conceptuel au format interne et 
réciproquement, 
— la transformation externe/conceptuelle permettant de faire passer 
des occurrences de données depuis le format conceptuel au format 
externe et réciproquement. 
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A titre d'exemple, la figure II.6 représente la transformation d'un 
ensemble d'occurrences de données depuis le format conceptuel indiqué 
au format externe indiqué. 


Données conceptuelles 





VÉHICULE N° VEH MARQUE | TYPE | COULEUR 





872 RH 94 | RENAULT R12 ORANGE 
940 HA 75 | PEUGEOT 204 VERTE 
895 ST 63 | CITROEN 2CV BLEUE 

















PERSONNE N* SS NOM PRÉNOM 








100 DUPONT | JACQUES 
200 DURAND PIERRE 














PROPRIÉTAIRE | N^ SS | N° VEH DATE 








100 872 RH 94 10.02.78 
200 940 HA 75 11.04.79 











Données externes 







PERSONNE PRÉNOM NOM 
JACQUES | DUPONT 


PIERRE DURAND 









872 RH 94 
940 HA 75 

















Fig. II.6. — Exemple de transformation de données 


Pour être capable d'effectuer automatiquement la transfot mation 
des données d’un niveau à un autre, un SGBD doit connaître les corres- 
pondances existant entre les niveaux. Pour cela, lors de la définition des 
schémas, le groupe d’administration des données doit expliciter com- 
ment les schémas se déduisent les uns des autres au moyen de règles de 
correspondance. 

Notion 7 : Règles de correspondance (Mapping rules) 


Paramètres définissant les procédures de transformation des données depuis un niveau de 
schéma dans un autre niveau. 
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Dans un système à trois niveaux de schémas, devraient donc exister : 


— des règles de correspondance interne à conceptuel, 
— pour chaque schéma externe, des règles de correspondance concep- 
tuel à externe. 


Dans les systèmes de gestion de bases de données classiques, les 
règles de correspondance permettant d'exécuter la transformation d'un 
niveau i à un niveau i— 1 sont bien souvent mélangées avec les schémas 
du niveau le plus élevé ou le plus bas. Il y a cependant intérét à distinguer 
ces deux notions. 


8.3. — Administration des données 


La définition des différents schémas et des régles de correspondance 
est théoriquement effectuée par les administrateurs de données. 


[osten 8 : Administrateur de données (Data Administrator) 
Personne responsable de la définition de schémas et de régles de correspondance. 


Dans un SGBD à trois niveaux de schémas, les administrateurs de don- 
nées ont trois róles : 


— administrateur de bases de données correspondant à la définition du 
schéma interne et des règles de correspondance interne à conceptuel, 
— administrateur d'entreprise correspondant à la définition du schéma 
conceptuel , 

— administrateur d'application correspondant à la définition des sché- 
mas externes et des régles de correspondance externe à conceptuel. 


Ces trois rôles peuvent être accomplis par les mêmes personnes ou 
par des personnes différentes. Un rôle essentiel est celui d'administrateur 
d'entreprise qui inclut la définition des informations que contient la base 
de données au niveau sémantique. Il inclut également la protection des 
données contre les abus et les mauvais usages. 


Finalement, les différents schémas et règles de correspondance sont 
stockés après compilation dans le dictionnaire des données, avec des com- 
mentaires éventuels. 


Ensemble des schémas et des règles de correspondance entre schémas associés à une 


|j 9 : Dictionnaire des données (Data dictionnary) 
base de données, combinés à une description de la signification des données. 


Le dictionnaire de données peut être lui-même implanté dans le 
systéme comme une base de données. Il constitue alors une méta-base, 
c’est-à-dire une base décrivant les autres bases. 
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4. ARCHITECTURE DE RÉFÉRENCE 


L'architecture de référence présentée correspond approximative- 
ment à l'architecture proposée par le groupe de travail ANSI/ 
X3/SPARC sur les systémes de bases de données. Elle est articulée autour 
du dictionnaire de données et comporte deux parties : 


— une partie permettant d'assurer la description des données et donc la 
composition du dictionnaire des données, 

— une partie permettant d'assurer la manipulation des données, c'est-à- 
dire l'interrogation et la mise à jour de la base. 


Dans chacune des parties, on retrouve les trois niveaux interne, 
conceptuel et externe. L'architecture proposée est représentée figure 
111.7. 


Les diverses interfaces indiquées correspondent successivement à : 


(1) Langage de description de données conceptuelles, format source ; ce lan- 
gage permet à l'administrateur d'entreprise de définir le schéma concep- 
tuel format source. 


(2) Langage de description de données conceptuelles, format objet ; ce langage 
résulte de la compilation du précédent et permet de ranger le schéma objet 
dans le dictionnaire des données. 


(3) Description de données conceptuelles, format d'édition : cette interface per- 
met aux administrateurs d'applications et de bases de consulter le schéma 
conceptuel afin de définir les régles de correspondance. 


(4) Langages de description de données externes, format source ; ces langages 
permettent aux administrateurs d'applications de définir les schémas exter- 
nes et les données de correspondance avec le schéma conceptuel ; il peut 
exister plusieurs langages de description externes car le systéme de gestion 
de bases de données peut supporter plusieurs modèles externes. 


(5) Langages de description de données externes, format objet ; ces langages 
correspondent à la compilation des précédents et permettent de ranger les 
schémas externes objets dans le dictionnaire des données. 


(6) Langages de description de données internes, format source ; ce langage 
permet à l'administrateur de base de données de définir le schéma interne 
et les régles de correspondance avec le schéma conceptuel. 


(7) Langage de description de données internes, format objet ; ce langage cor- 
respond à la compilation du précédent et permet de ranger le schéma 
interne objet dans le dictionnaire des données. 


(8 Langages de manipulation de données externes, format source ; ces langa- 
ges permettent aux programmeurs d'applications, voire aux non informa- 
ticiens, de manipuler les données vues au travers d'un schéma externe. 
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Fig. 111.7. — Architecture de référence pour un SGBD 
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(9) Langages de manipulation externes, format objet; ces langages corres- 
pondent aux formats compilés des précédents. 

(10) Langage de manipulation de données conceptuelles, format objet : ce lan- 
gage unique est produit par les processeurs de transformation externe à 
conceptuel afin de manipuler les données vues au travers du schéma concep- 
tuel. 


(11) Langage de manipulation de données interne, format objet ; ce langage uni- 
que est construit par le processeur de transformation conceptuel à interne 
afin de manipuler les données internes. 

(12) Langage de stockage de données, format objet ; ce langage correspond à 
l'interface du systéme de stockage des données. 

(13) Interface mémoires secondaires ; cette interface permet d'effectuer les 
entrées-sorties sur les disques. 

(14) Interface d'accès au dictionnaire des données : cette interface permet aux 
divers processeurs transformateurs d'accéder aux schémas objets et aux 
régles de correspondance. 


Les fonctions de chacun des processeurs indiqués sont les suivantes. 
Le processeur de schéma conceptuel compile le schéma conceptuel et, 
dans le cas où il n'y a pas d'erreur, range ce schéma compilé dans le dic- 
tionnaire des données. Le processeur de schéma externe compile les sché- 
mas externes et les régles de correspondance externe à conceptuel et, 
dans le cas sans erreur, range le schéma compilé et les règles de corres- 
pondance dans le dictionnaire des données. Le processeur de schéma 
interne a un róle symétrique pour le schéma interne. Le processeur de 
transformation externe à conceptuel transforme les manipulations exter- 
nes en manipulations conceptuelles et dans l'autre sens les données 
conceptuelles en données externes. Le processeur de transformation 
conceptuel à interne transforme les manipulations conceptuelles en 
manipulations internes et dans l'autre sens les données internes en don- 
nées conceptuelles. Finalement, le processeur de transformation interne 
à stockage transforme les manipulations internes en primitives du 
systéme de stockage et délivre les données stockées en format correspon- 
dant au schéma interne. 


5. QUELQUES ARCHITECTURES DE SYSTEMES OPÉRATIONNELS 


5.1. — L'architecture du DBTG CODASYL 


Le groupe de travail « Data Base Task Group » du comité 
CODASYL responsable du développement de COBOL a proposé des 
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recommandations pour construire un système de bases de données 
depuis 1971 [Codasyl 71]. Ces recommandations comportent essentielle- 
ment des langages de description de données et de manipulation de don- 
nées orientées COBOL que nous étudierons au chapitre VI, mais aussi 
une recommandation d'architecture. 


L'architecture d'un système obéissant aux recommandations 
CODASYL s'articule autour du schéma qui permet de définir les arti- 
cles, leurs données et les liens entre ces articles. Ce schéma peut être assi- 
milé au schéma conceptuel de l'architecture ANSI/X3/SPARC, bien 
que comportant, à notre avis, pas mal de notions du niveau interne. La 
structure de stockage des données est définie par le schéma de stockage 
qui correspond plus ou moins au schéma interne ANSI. La notion de 
schéma externe est définie pour COBOL et appelée sous-schéma. Un 
groupe de travail a également proposé des langages de description de 
sous-schémas pour FORTRAN ainsi qu'un langage de manipulation 
associé. L'architecture globale est représentée figure III.8. 


PROGRAMME USAGER PROGRAMME USAGER 
COBOL {OU FORTRAN) COBOL (OU FORTRAN) 


travail 


T 
A 
M 
P 
o 
N 
S 





(interne) 


Fig. 111.8. = Architecture d'un système CODASYL (les schémas sont hachurés) 
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5.2. — L'architecture des systèmes relationnels 


5.2.1. — Vue générale 


Les systémes relationnels permettent d'organiser les données en 
tables. Ils sont de plus en plus nombreux. La plupart comportent un 
schéma relationnel qui permet de décrire les tables implantées sur dis- 
ques, et des vues qui correspondent aux schémas externes et décrivent en 
conséquence les tables utilisées par les usagers. Au schéma relationnel 
sont en général associées des données de niveau interne décrivant les che- 
mins d'accés et accélérateurs d'accés (index, liens...) aux tables. Aux 
vues sont associées des questions relationnelles qui constituent les régles 
de transformation permettant d'élaborer les tables vues par les usagers. 


5.2.2. — Le système SQL/DS (système R) 


Le produit IBM SQL/DS, issu du systéme de recherche appelé 
système R, est un cas typique de système relationnel. Son architecture est 
divisée en trois composants majeurs [Astrahan 76] : 

e Data System Control (DSC). Ce composant assure les communica- 
tions du systéme de bases de données avec les autres programmes (CICS, 
etc.). Il contrôle l'initialisation et la terminaison de SQL/DS et agit 
comme le superviseur du système, Il permet également plusieurs usagers 
simultanés. 

e Relational Data System (RDS). Ce composant translate les requétes 
relationnelles en modules d'accés aux tables implantées sur disques. I 
gère les vues, détermine les meilleurs chemins d’accès et en général effec- 
tue la compilation des requétes en provenance des usagers. 

e Data Base Storage System (DBSS). Ce composant effectue les accés 
demandés par les modules générés par RDS. Il gére également les alloca- 
tions d'espace disques, les problémes d'accés concurrents et les reprises 
en cas de pannes. Il utilise VSAM pour accéder aux fichiers. 


La figure III.9 résume l'architecture de SOL/DS. 


5.2.3. — Le systéme INGRES 


Le système INGRES [Stonebraker 76] réalisé à BERKELEY et 
commercialisé sur les mini-ordinateurs de DIGITAL EQUIPEMENT est 
un autre exemple de système relationnel. INGRES est construit autour 
du systéme UNIX. Le SGBD se compose de quatre composants : 


e Process 1. Il s'agit d'un moniteur interactif de terminaux. Il permet à 
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l'usager devant un terminal de formuler, imprimer, modifier et lancer 
l'exécution des commandes de INGRES. En résumé, il assure donc les 


communications avec les usagers. 
* Process 2. Ce composant accomplit essentiellement l'analyse syntaxi- 


que des requêtes, la modification des questions afin de supporter les 
vues, la protection et le contróle de cohérence des données, et enfin, le 
contróle des accés concurrents aux données. 
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* Process 3. Ce composant décompose les requêtes portant sur plusieurs 
tables en une suite de requétes plus simples, portant sur une table uni- 
que. Il accéde également aux données afin de traiter les requétes mono- 
table. 


* Process 4. Ce composant comporte un ensemble d'utilitaires (création 
de tables, création d'index, destructions...) et également prend en charge 
les problémes de résistance aux pannes en retardant les mises à jour 
jusqu'à la fin du programme. L'architecture du systéme INGRES est 
représentée figure III.10. 


5.3. — L'architecture des machines bases de données 


Plusieurs machines bases de données sont aujourd'hui commerciali- 
sées ou à l'étude [Dewitt 81]. Ces machines sont en fait des calculateurs 
plus ou moins spécialisés, et plus ou moins multiprocesseurs, effectuant 
la gestion de données, et connectés à un ou plusieurs calculateurs hótes. 
La machine recoit les commandes du calculateur hóte par l'intermédiaire 
de messages codés conformément à un protocole, appelé protocole de 
manipulation de données. Une machine base de données se compose en 
général de quatre types de modules : 


e des processeurs de recherche. Encore appelés filtres, ils sont chargés 
d'effectuer la sélection des données recherchées ainsi que leur enregistre- 
ment sur les pistes des disques. Il peut en exister un par groupe de dis- 
ques, par disque ou à la limite par piste. 


* le noyau du systéme de bases de données. Ce noyau est généralement 
relationnel (bien qu'il existe des machines à noyau basé sur un modéle 
d'accés). Il accomplit la gestion des chemins d'accés aux données et la 
recherche des accés de coüt minimum pour répondre aux requétes qu'il 
recoit. Le noyau prend en charge également la résistance aux pannes, la 
gestion des accés concurrents et des mémoires tampons. Un processeur 
dédié exécute en général le noyau. 


* la gestion des vues, de l'intégrité et de la sécurité. Peu de machines 
permettent cette gestion qui est souvent laissée à la charge du calculateur 
hóte. Certaines machines supportent cependant des vues basées sur dif- 
férents modéles, par exemple relationnel, réseau et hiérarchique. 

o [a gestion des communications. Elle prend une dimension importante 
du fait de la séparation du systéme de bases de données du calculateur 
hóte. La connexion peut étre accomplie par un réseau de communication 
ou un canal. En général, la gestion des communications est effectuée par 
un processeur spécialisé. 
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Une architecture type d’un système avec machine bases de données 
est représentée figure IIL.11. 
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Fig. 111.11. — Architecture type d'un système avec machine bases de données 
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Fig. 111.12, — Architecture de l'IDM.500 de Britton-lee, 


De maniére plus spécifique, l'architecture de la machine IDM.500 
de Britton-Lee [Britton-Lee 81] est représentée figure III.12. Celle de la 
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machine iDBP de Intel [Intel 82] est représentée figure III.13. A noter 
que cette derniére supporte des vues reconstruites avec différents modè- 
les de données sur un schéma conceptuel relationnel. Il semblerait qu'il 
s'agisse là d'un des premiers systémes réels avec trois niveaux de schémas 
bien distingués et capable de supporter plusieurs modéles de données. La 
future machine COPERNIQUE [Arminsen 81] devrait aussi supporter 
des vues multi-modéles, mais avec seulement deux niveaux de schémas. 
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Fig. 11.13. — Architecture de l'iDBP de INTEL 


6. CONCLUSION 


Dans ce chapitre, nous avons présenté les objectifs des systémes de 
gestion de bases de données, puis les concepts et méthodes essentiels de 
ces systémes. Ceci nous a conduit à étudier l'architecture de référence 
ANSI/X3/SPARC, puis quelques architectures de systémes existants. 


La nécessité de développer des systémes multi-modéles, à langages 
externes variés, avec un dictionnaire incluant une définition précise en 
langage naturel des données, conduit aujourd'hui à rechercher une nou- 
velle architecture de référence pour les SGBD. Ainsi, le National Bureau 
of Standards (NBS) a récemment publié un rapport réalisé par Computer 
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Corporation of America (CCA) proposant et détaillant l’architecture 
représentée figure III. 14. Une telle architecture est assez voisine de celle 


retenue dans le projet SABRE [Gardarin 82]. 
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Fig. 111.14. — Vers une nouvelle architecture de référence 
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IV. LE MODÈLE RELATIONNEL 


1. INTRODUCTION 


Au chapitre III, nous avons défini un modèle de données comme un 
ensemble de concepts et de régles de composition de ces concepts permet- 
tant de décrire des données. Il existe en fait trois modéles de données 
principaux : le modèle hiérarchique, le modèle réseau et le modèle rela- 
tionnel. Les deux premiers sont qualifiés de modèle d’accès et nous les 
étudierons au chapitre VI. Le dernier est l’objet du présent chapitre. 


Le modèle relationnel a été inventé par CODD à IBM-San Jose en 
1970 [Codd 70]. Il est basé sur des concepts très simples. Cependant, la 
plupart des systèmes commercialisés jusqu'à 1980 utilisaient le modèle 
réseau ou le modèle hiérarchique. Cette tendance tend aujourd’hui à 
s'inverser [Won Kim 79] ; des systèmes supportant plusieurs modèles 
apparaissent aussi. 


Au modèle relationnel est associée une théorie qui ne peut être sépa- 
rée du modèle : la théorie de la normalisation des relations. Cette théorie 
a pour but d'éliminer les comportements anormaux des relations lors des 
mises à jour. Elle permet aussi d'éliminer les données redondantes et de 
mieux comprendre les relations sémantiques entre données. 


Ce chapitre est organisé comme suit. Au paragraphe 2, les concepts 
de base du modéle relationnel sont introduits, à l'exception du concept 
de clé, défini plus formellement au paragraphe 5. Le paragraphe 3 intro- 
duit les objectifs des méthodes de conception des schémas relationnels. 
Le paragraphe 4 présente la notion de dépendance fonctionnelle et le 
paragraphe 5 les trois premiéres formes normales qui en découlent. Le 
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paragraphe 6 traite des dépendances multivaluées et de la quatrième 
forme normale. Le paragraphe 7 introduit les dépendances de jointures 
et la cinquième forme normale encore appelée forme normale pour 
projection-jointure. 


2. LES CONCEPTS DE BASE DU MODÈLE 


Le concept de relation découle directement de la théorie des ensem- 
bles. Nous allons en rappeler la définition qui nécessite tout d’abord 
l'introduction de la notion de domaine. 


Notion 1 : Domaine (Domain) 
Ensemble de valeurs. 


A titre d'exemple, on peut considérer le domaine des entiers 

E = [O, +1, € 2,.. + o], 
celui des réels, celui des booléens (0, 1}, le domaine des couleurs du dra- 
peau frangais composé des valeurs 

(BLEU, BLANC, ROUGE] etc. 


Rappelons que le produit cartésien d'un ensemble de domaines D1, 
D2, ... D, noté D1 x D2... x D, est l'ensemble des n-uplets ou tuples 
< Vi, Vj... V, > tels que v; e D. Par exemple, le produit cartésien des 
domaines D1 = (BLEU, BLANC, ROUGE) et D2 = {0,1} est composé 
de six tuples représentés figure IV.1. 





























BLEU 0 
BLEU 1 
BLANC 0 
BLANC 1 
ROUGE 0 
RONGE : Fig. IV.1. — Exemple de produit cartésien 
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Nous pouvons maintenant introduire la notion de relation. 


Notion 2 : Relation (Relation) | 
Sous-ensemble du produit cartésien d’une liste de domaines. 
Une relation est généralement caractérisée par un nom. 


Par exemple, à partir des domaines 
DI = (BLEU, BLANC, ROUGE] et D2 = {0,1} 
on peut composer la relation CIEL représentée figure IV.2 : 

















CIEL DI D2 
BLEU o 
BLEU 1 
BLANC 0 














Fig. IV.2, — Un exemple de relation 


Plus simplement, une relation peut être vue comme un tableau à deux 
dimensions dont les colonnes correspondent aux domaines et les lignes 
contiennent les tuples. On parle parfois de table. 


En fait, afin de rendre l’ordre des colonnes sans importance tout en 
permettant plusieurs colonnes de même domaine, on associe un nom à 
chaque colonne. 


Notion 3 : Attribut (Attribute) 
Colonne d'une relation caractérisée par un nom. 


En première approche, un schéma de relation est le nom de la rela- 
tion suivi de la liste des attributs avec leurs domaines. Ainsi, à toute rela- 
tion, il est possible d'associer un schéma de relation qui représente (au 
moins en partie) l'intention de la relation, alors que le tableau avec les 
tuples représente une extension possible. 


Par exemple, une relation décrivant des voitures et comportant les at `i- 
buts : numéro de véhicule NV, MARQUE, TYPE, PUISSANCE, COU- 
LEUR, aura pour schéma : 
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VOITURE (NV : entier, MARQUE : caractère (10), TYPE : caractère 
(4), PUISSANCE : entier, COULEUR : couleur). 


Afin de simplifier, on ne précise en général pas les domaines. 


Nous pouvons maintenant introduire la notion de base de données 
relationnelle. 


Notion 4 : Base de données relationnelle (Relational database) 
Base de données dont le schéma est un ensemble de schémas de relations et dont les 
occurrences sont des tuples de ces relations. 


3. INTRODUCTION A LA CONCEPTION 
DE SCHÉMAS RELATIONNELS 


3.1. — Perception du monde réel 


Le monde réel peut étre modélisé à l'aide d'entités qui représentent 
les objets ayant une existence visible, et d'associations entre ces objets 
[Benci 76, Chen 76]. A titre d'exemple, soient des données modélisant 
des entités « personne » et « voiture », et le type d'association « pos- 
séde » qui traduit le fait qu'une personne est propriétaire d'une ou plu- 
sieurs voitures. Une personne est caractérisée par un numéro de Sécurité 
Sociale (NSS), un nom et un prénom alors qu'une voiture est caractérisée 
par les attributs déjà vus NV, MARQUE, TYPE, PUISSANCE et COU- 
LEUR. Chaque personne est identifiée par une occurrence du numéro de 
Sécurité Sociale (NSS) alors que chaque voiture est identifiée par un 
numéro de véhicule (NV). A chaque occurrence d'association corres- 
pond par exemple une date d'achat (DATE) et un prix d'achat (PRIX). 
La figure IV.3 illustre la partie du monde réel modélisée en représentant 
une entité par un rectangle, une association par un hexagone et un attri- 
but par un cercle. Le modéle de perception du réel utilisé est le modèle 


entité-association décrit dans [Chen 76]. 
PUISSAN 
CE 


-) NOM ( PRENOM COULEUR 
NO 


Fig. IV.3. — Représentation du monde réel par des entités et des associations 
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Le modèle relationnel se prête bien à la représentation des entités et 
des associations. Une entité est représentée par une relation (table) dont 
le schéma est le nom de l’entité suivi de la liste des attributs de l’entité. 
Par exemple, les entités PERSONNE et VOITURE seront respective- 


ment représentées par les relations : 


PERSONNE (NSS, NOM, PRÉNOM) 
VOITURE (NV, MARQUE, TYPE, PUISSANCE, COULEUR). 


Une association est représentée par une relation dont le schéma est le 
nom de l'association, suivie de la liste des identifiants des entités partici- 
pantes et des attributs de l'association. Par exemple, l'association pos- 
séde sera représentée par la relation : 


POSSEDE (NSS, NV, DATE, PRIX). 


3.2. — Problèmes soulevés par une mauvaise perception du réel 


Une mauvaise conception des entités et associations représentant le 
monde réel modélisé conduit à des relations problématiques. Imaginons 
par exemple que l'on isole une entité unique PROPRIETAIRE conte- 
nant tous les attributs des trois relations PERSONNE, VOITURE et 
POSSEDE. Ainsi, nous pourrions représenter toutes les informations 
modélisées par une seule relation. La figure IV.4 représente une exten- 
sion possible de cette relation. 


PROPRIÉTAIRE 


NV MARQUE | TYPE |PUISS,| PRÉNOM| DATE 














672 RH 75|RENAULT 'R12TS MARTIN Jacques |10.02.75 
800 AB 64 PEUGEOT MARTIN Jacques |11.06.80 
686 HK 75| CITROEN | 2CV DUPOND Pierre 20.04.76 
720 CD 60| CITROEN | AMI8 DUPOND Pierre |20.08.80] 
400 XY 75 RENAULT | R18B FANTOMAS| Yves |11.09.81 























Fig. IV.4. — Extension de la relation Propriétaire 


La relation représentée figure IV.4 souffre de plusieurs types d’ano- 
malies [Codd 72, Fagin 81] : 
— tout d’abord, des données sont redondantes ; par exemple, MAR- 
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TIN Jacques et DUPOND Pierre apparaissent deux fois ; plus générale- 
ment, une personne apparaît autant de fois qu’elle possède de voitures ; 
— ces redondances conduisent à des risques d'incohérences lors des 
mises à jour; par exemple, si l’on s’aperçoit que le prénom de 
DUPOND n'est pas Pierre mais Jean, il faudra veiller à mettre à jour les 
deux tuples contenant DUPOND, sous peine de voir apparaitre un 
DUPOND Pierre et un DUPOND Jean ; 


— il est nécessaire d'autoriser la présence de valeurs nulles dans une telle 
relation afin de pouvoir conserver des voitures sans propriétaire ou des 
personnes ne possédant pas de voitures dans la base. 


En résumé, une relation qui ne représente pas de vraies entités ou 
associations semble donc souffrir de présence de données redondantes et 
d'incohérences potentielles et nécessite le codage de valeurs nulles. Il y a 
tout intérét à éliminer ces anomalies afin de faciliter la manipulation des 
relations. 


3.3. — L'approche par décomposition 


L'approche par décomposition pour concevoir des schémas relation- 
nels tend à partir d'une relation composée de tous les attributs, appe- 
lée la relation universelle, et à décomposer cette relation en sous- 
relations qui ne souffriraient pas des anomalies précédemment signalées. 
Le processus est un processus de raffinement successif qui doit aboutir 
(au moins on l'espère) à isoler des entités et des associations du monde 
réel. Il doit être réalisé par un algorithme à partir d'une bonne compré- 
hension des propriétés sémantiques des données. Cette approche est 
illustrée par la figure IV.5. 


La compréhension de la théorie de la décomposition des relations 
nécessite la connaissance de deux opérations élémentaires de manipula- 
tion de relations [Codd 70]. Tout d'abord, /a projection : la projection 
est l'opération qui consiste à supprimer des attributs d'une relation et à 
éliminer les tuples en double qui risquent d'apparaitre dans la nouvelle 
relation obtenue. La projection de la relation R de schéma R (A,, A, ... 
An) sur les attributs Ai,, Ab... Ai, (avec i;  i,) est une relation R’ de 
schéma R’ (Ai, , Ai; ... Ai, ) obtenue par élimination des valeurs des attri- 
buts de R n'appartenant pas à R' et suppression des tuples en double. 
Une telle projection R’ sera notée ici II Ai, Ai; ... Ai, (R). 


Par exemple, la projection de la relation PROPRIÉTAIRE repré- 
sentée figure IV.4 sur les attributs NOM, PRÉNOM est représentée 
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figure IV.6. La projection permet ainsi de décomposer une relation en 
sous-relations. 
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Les attributs de la relation universelle A 
entités { PERSONNE (NSS, NOM, PRÉNOM) 


et 4 VOITURE (NV, MARQUE, TYPE, PUISS., COUL.) 
associations | POSSEDE (NSS, NV, DATE, PRIX) 


Fig. IV.5. — Le processus de décomposition 












II NOM, PRÉNOM (PROPRIÉTAIRE) PRÉNOM 











MARTIN 
DUPOND 
FANTOMAS 


Jacques 
Pierre 
Yves 





Fig. IV.6. — Exemple de projection 


L'opération inverse de la projection est la jointure naturelle ou sim- 
plement jointure. La jointure naturelle de deux relations R et S, de 
schéma respectif R (A;, A, ... An) et S (B,, B, ... Bp) est une relation T 
ayant pour attributs l'union des attributs de R et S, soit : 


(A, Ag ... An] U [B], Bo, ... Bp] 


et pour tuples tous ceux obtenus par concaténation des tuples de R et S 
ayant mêmes valeurs pour les attributs de méme nom. Ainsi, on a : 
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La jointure naturelle est une opération commutative et associative. La 
figure IV.7 illustre la jointure naturelle de deux relations R et S, que l'on 















































note R X S. 

R MARQUE | COULEUR S | COULEUR | PUISSANCE 
RENAULT ROUGE ROUGE 6 
PEUGEOT VERTE VERTE 9 
CITROEN BLEUE BLEUE 2 
RENAULT VERTE BLEUE 5 

VERTE 6 
RS MARQUE | COULEUR | PUISSANCE 
RENAULT ROUGE 6 
PEUGEOT VERTE 9 
PEUGEOT VERTE 6 
CITROEN BLEUE 2 
CITROEN BLEUE 5 
RENAULT VERTE 9 
RENAULT VERTE 6 
—L. 

















Fig. IV.7. — Exemple de jointure naturelle 


Il est maintenant possible d'introduire plus précisément la notion de 
décomposition [Ullman 80]. 


Notion 5 : Décomposition (Decomposition) 
Remplacement d'une relation R (A,, À, ... An) par une collection de relations R1, R2, 
... Rn obtenues par des projections de R et telles que la relation résultat des join- 


tures R1PXI R2bX ... Rn ait méme schéma que R. 


Par suite, lors d'une décomposition, le schéma de relation R (A,, A, ... 
An) est remplacé par une collection de schémas dont l'union des attri- 
buts est (A1, A2 ... An). A titre d'illustration, la figure IV.8 donne deux 
décompositions possibles pour la relation VOITURE. 
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VOITURE NY MARQUE | TYPE PUISS. | COUL. 
872 RH 75 | RENAULT | RI2TS 6 BLEUE 
975 AB 80 | RENAULT | RI2TS 6 ROUGE 
Décomposition "d Décomposition 2 
RI| NV TYPE | COUL. vi | NV | TYPE 
872 RH 75 | RI2TS | BLEUE 872 RH 75 | RI2TS 
975 AB 80 | RI2TS | ROUGE 975 AB 80 | RI2TS 




















R2 TYPE MARQ. | PUISS. V2 TYPE PUISS. | COUL. 














BLEUE 
ROUGE 


RI2TS | RENAULT 6 RI2TS 
RI2TS 








sa 

















V3 | TYPE MARQUE 














RI2TS | RENAULT 


Fig. IV.8. — Deux décompositions possibles de la relation voiture 


Parmi les deux décompositions représentées figure IV.8, si l’on 
admet qu’à un type de véhicule sont associées une seule marque et une 
seule puissance (ce qui est vrai pour les tuples figurant sur des cartes gri- 
ses), l’une est plus plaisante que l’autre : la décomposition 1 permet de 
retrouver toutes les informations par jointure, alors que la décomposi- 


tion.2 ne permet pas de retrouver la couleur d'un véhicule ; la jointure 
“V1 V2 


3:est différente de la relation initiale VOITURE. Ainsi, on 
est amené à introduiré là notion de décomposition sans perte. 





Notion 6 : Décomposition sans perte (Lossless join decomposition) 
Décomposition d'une relation R Rt, R2, ... Rn telle Ple pour toute extension de R, on 
ait : = RIDA R2M .. 
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Le problème de la conception des bases de données relationnelles peut 
donc être vu comme celui de décomposer la relation universelle compo- 
sée de tous les attributs en sous-relations ne souffrant pas des anomalies 
vues en 3.3. et de sorte à obtenir une décomposition sans perte. Nous 
allons ci-dessous étudier les principales méthodes proposées pour effec- 
tuer une telle décomposition qui doit permettre de déterminer des entités 
et associations canoniques du monde réel, donc en fait de construire un 
schéma conceptuel. 


4. DÉPENDANCES FONCTIONNELLES 


4.1. — Notion de dépendance fonctionnelle 


La notion de dépendance fonctionnelle fut introduite par CODD 
[Codd 70] afin de caractériser des relations qui peuvent étre décompo- 
sées sans perte d'informations. 


Notion 7 : Dépendance Fonctionnelle (Functional Dependency) 
Soit R (A1, A2 ... An) un schéma de relation, et X et Y des sous-ensembles de (A1, A2, ... 
An}. On dit que X — Y (X détermine Y, ou Y dépend fonctionnellement de X) si pour toute 
extension r de R, pour tout tuple t1 et t2 de r, on a : 

TIX (t1) = IX (t2) = TY (t1) = IIY (t2) 


Plus simplement, un attribut (ou groupe d’attributs) Y dépend fonction- 
nellement d'un attribut (ou groupe d'attributs) X, si, étant donné une 
valeur de X il lui correspond une valeur unique de Y (et ceci quel que soit 
l'instant considéré). 


A titre d'exemple, dans la relation VOITURE, on a les dépendances 
fonctionnelles : 


NV — COULEUR 
TYPE - MARQUE 
TYPE — PUISSANCE 
(TYPE, MARQUE) — PUISSANCE 


Par contre, les dépendances fonctionnelles suivantes sont inexistantes : 


PUISSANCE + TYPE 
TYPE + COULEUR 


| 
H 
| 





Le modèle relationnel 75 


Il est essentiel de bien remarquer qu’une dépendance fonctionnelle 
(en abrégé, DF) est une assertion sur toutes les valeurs possibles et non 
pas sur les valeurs actuelles : elle caractérise une intention et non pas une 
extension d'une relation. Autrement dit, il est impossible de déduire les 
DF d'une réalisation particuliére d'une relation. La seule maniére de 
déterminer une DF est de regarder soigneusement ce que signifient les 
attributs car ce sont des assertions sur le monde réel qui lient les valeurs 
possibles des attributs entre elles. Les DF devraient ainsi étre déclarées 
par l'administrateur d'entreprise au niveau du schéma conceptuel et un 
bon SGBD devrait les faire respecter. 


4.2. — Propriétés des dépendances fonctionnelles 


Les DF obéissent à plusieurs régles d'inférences triviales. 


1. Réflexivité: Y € X = X — Y ; cette règle stipule que tout ensemble 
d'attributs détermine lui-même ou une partie de lui-même. 


2. Augmentation : X — Y = XZ — YZ ; cette règle signifie que si X 
détermine Y, les deux ensembles d'attributs peuvent étre enrichis par un 
même troisième. 

Une règle d'inférence moins triviale est la transitivité : 
3. Transitivité : X — Y et Y—Z => X-Z 

Par exemple, des dépendances : 


NV = TYPE et TYPE — PUISSANCE 
on déduit : NV — PUISSANCE 


Les trois régles précédentes composent les axiomes des dépendances 
fonctionnelles et sont connues dans la littérature sous le nom « Axiomes 
de Armstrong » [Armstrong 74]. Plusieurs autres régles se déduisent des 
axiomes : 


4. Union : X=Y et X-Z => X — YZ 
5. Pseudo-transitivité: X — Y et WY — Z => WX =Z 
6. Décomposition < X- Ye ZsY => X-Z. 


A partir de ces règles, il est possible d'introduire la notion de dépen- 
dance fonctionnelle élémentaire [Melkanoff 82]. 


Notion 8 : Dépendance fonctionnelle élémentaire (Elementary fonctional dependancy) 
Dépendance fonctionnelle de la forme X =+ A, où A est un attribut unique non inclus dans 
X (A € X) et oü il n'existe pas X' c X tel que X^ — A. 
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La seule règle d'inférence qui s'applique aux dépendances fonctionnelles 
élémentaires est la transitivité. 


4.3. — Graphe des dépendances fonctionnelles 


Soit un ensemble F de dépendances fonctionnelles élémentaires. 
Dans le cas où tous les attributs gauches sont uniques, il est possible de 
visualiser cet ensemble de DF par un graphe appelé graphe des dépen- 
dances fonctionnelles. A titre d'exemple, considérons l'ensemble de 
dépendances fonctionnelles entre les attributs de la relation VOITURE : 


F = (NV — TYPE; TYPE — MARQUE ; TYPE — PUISSANCE ; 
NV — COULEUR]. 


Le graphe associé est représenté 
figure IV.9. 







COULEUR 


MARQUE 
PUISSANCE 


Il n’est pas toujours possible de représenter les DF d'une relation 
par un graphe simple : dans le cas où une partie gauche d'une DF com- 
porte plus d'un attribut, il faut introduire des arcs représentant une asso- 
ciation de plusieurs sommets vers un sommet. Par exemple, la relation 


CODE POSTAL (CODE, VILLE, RUE) 






Fig. IV.9. — Exemple de graphe des DF 


comporte les DF : 


(VILLE, RUE) — CODE 
CODE -- VILLE 


représentées par le réseau de la figure IV.10. 


Fig. IV.10. — Exemple de réseau de DF (sue) 
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4.4. — Fermeture transitive et couverture minimale 


A partir d’un ensemble de DF élémentaires, on peut composer par 
transitivité d’autres DF élémentaires. On aboutit ainsi à la notion de fer- 
meture transitive d’un ensemble F de DF élémentaires. 


Notion 9 : Fermeture transitive (Transitive closure) 


Ensemble des DF élémentaires considérées enrichi de toutes les DF élémentaires déduites 
par transitivité. 


Par exemple, à partir de l'ensemble de DF : 


F x (NV — TYPE; TYPE — MARQUE ; TYPE — PUISSANCE ; 
NV — COULEUR] 


on déduit la fermeture transitive : 


F+ = FU (NV — MARQUE ; NV — PUISSANCE]. 


Le graphe correspondant à F* est représenté figure IV.11. 


COULEUR, 


Fig. IV.11. — Exemple de fermeture 
transitive 





A partir de la notion de fermeture transitive, il est possible de défi- 
nir l'équivalence de deux ensembles de DF élémentaires : deux tels 
ensembles sont équivalents s’ils ont la même fermeture transitive. Par 
suite, il est intéressant de déterminer un sous-ensemble minimum de DF 
permettant de générer toutes les autres. 


Notion 10 : Couverture Minimale (Minimal Cover) 

Ensemble F de DF élémentaires associé à un ensemble d'attributs vérifiant les propriétés 
suivantes : 

1. aucune dépendance dans F n'est redondante ; c'est-à-dire, pour toute DF f de F, F-f 
n'est pas équivalent à F ; 

2. toute DF élémentaire des attributs est dans la fermeture transitive de F {notée F+), 





i 
i 
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II a été montré que tout ensemble de DF a une couverture minimale 
qui n'est en général pas unique. Par exemple : 


F = (NV — TYPE; TYPE — MARQUE ; TYPE — PUISSANCE ; 
NV — COULEUR] 


est une couverture minimale pour l'ensemble des DF de voiture. La cou- 
verture minimale va être un élément essentiel pour décomposer les rela- 
tions sans perte d'informations. 


5. NOTION DE CLÉ ET TROIS PREMIÈRES FORMES NORMALES 


5.1. — Clé de relation 


La notion de clé de relation est un concept essentiel du modèle rela- 
tionnel. Bien que la notion intuitive de clé soit bien connue, il est possi- 
ble d'en donner une définition plus formelle à partir de celle de dépen- 
dance fonctionnelle. 


Notion 11 : Clé de relation (Relation Key) 

Sous ensemble X des attributs d'une relation R (A1, A2 ... A2) tel que : 
1. X — A1 A2... An 

2. || n'existe pas de sous-ensemble Y c X tel que Y — A1 A2 ... An. 


En clair, une clé est un ensemble minimum d'attributs qui détermine 
tous les autres. Par exemple, NV est une clé de la relation VOITURE 
alors que (NV, TYPE) n'est pas une clé. Il peut y avoir plusieurs clés 
pour une même relation ; on en choisit en général une comme clé pri- 
maire. On parle parfois de clé candidate pour désigner une clé quelcon- 
que. 


5.2. — Définition des trois premières formes normales 


Les trois premiéres formes normales ont pour objectif de permettre 
la décomposition de relations sans perdre d'informations, à partir de la 
notion de dépendance fonctionnelle [Codd 72]. L'objectif de cette 
décomposition est d'aboutir à un schéma conceptuel représentant les 
entités et les associations canoniques du monde réel. 
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La première forme normale permet simplement d'obtenir des tables 
rectangulaires. 


Notion 12 : Première Forme Normale (First Normal Form) 
Une relation est en première forme normale si tout attribut contient une valeur atomique. 


Cette forme normale est justifiée par la simplicité et l'esthétique. Elle 
consiste simplement à éviter les domaines composés de plusieurs valeurs. 
Par exemple, la relation PERSONNE (NOM, PRÉNOMS) sera ainsi 
décomposée en PERSONNE 1 (NOM, PRÉNOM 1) et PERSONNE 2 
(NOM, PRÉNOM 2). 


La deuxiéme forme normale permet d'assurer l'élimination de cer- 
taines redondances en garantissant qu'aucun attribut n'est déterminé 
seulement par une partie de la clé. 


Notion 13 : Deuxième forme normale (Second normal form) 
Une relation R est en deuxiéme forme normale si et seulement si : 
1. Elle est en première forme ; 


2. Tout attribut n'appartenant pas à une clé ne dépend pas que d'une partie de cette clé. 


Par exemple, considérons une relation 


FOURNISSEUR (NOM, ADRESSE, ARTICLE, PRIX) 


La clé est le couple (NOM, ARTICLE). On a les DF : 
(NOM, ARTICLE) — PRIX et NOM — ADRESSE. 


Par suite, une partie de la clé (NOM) détermine un attribut n'apparte- 
nant pas à la clé. Cette relation n'est donc pas en deuxiéme forme nor- 
male. Elle pourra étre décomposée en deux relations : 


FOURNISSEUR (NOM, ADRESSE) 
PRODUIT (NOM, ARTICLE, PRIX) 


qui elles, sont en deuxiéme forme normale. 


La troisiéme forme normale permet d'assurer l'élimination des 
redondances dues aux dépendances transitives. 


Notion 14 : Troisième forme normale (Third normal form) 

Une relation R est en troisiéme forme normale si et seulement si : 

1. elle est en deuxième forme ; 

2. tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé. 
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A titre d'illustration, la relation 


VOITURE (NV, MARQUE, TYPE, PUISSANCE, COULEUR) 


n'est pas en troisiéme forme normale. En effet, l'attribut non clé TYPE 
détermine MARQUE et aussi PUISSANCE. En effet, cette relation peut 
être décomposée en deux relations : 


VOITURE (NV, TYPE, COULEUR) 
MODÉLE (TYPE, MARQUE, PUISSANCE). 


Dans le cas où la relation possède une seule clé primaire, il est possi- 
ble de donner une définition équivalente comme suit. Une relation R est 
en troisiéme forme normale si et seulement si : 

1. elle est en deuxiéme forme normale, 
2. tout attribut n'appartenant pas à la clé ne dépend pas transitivement 
de la clé. 


Par exemple, dans la relation VOITURE, l’attribut MARQUE dépend 
transitivement de la clé ainsi que l'attribut PUISSANCE : 


NV — TYPE — PUISSANCE, 
NV — TYPE — MARQUE. 


5.3. — Propriétés d'une décomposition en troisième forme normale 


Les dépendances fonctionnelles sont des régles indépendantes du 
temps que doivent vérifier les valeurs des attributs. Il est nécessaire 
qu'une décomposition préserve ces régles. 


Notion 15 : Décomposition préservant les dépendances fonctionnelles (Dependencies 
preserving decomposition) 

Décomposition (R1, R2, ... Rn} d'une relation R telle que la fermeture transitive des DF de 

R est la même que celle de l'union des DF de (R1, R2, ... Rn}. 


A titre d'exemple, la décomposition de la relation VOITURE (NV, 
MARQUE, TYPE, PUISSANCE, COULEUR) en R1 (NV, TYPE, 
COULEUR) et R2 (TYPE, MARQUE, PUISSANCE) préserve les DF, 
alors que la décomposition en V1 (NV, TYPE), V2 (TYPE, PUIS- 
SANCE, COULEUR), V3 (TYPE, MARQUE) ne les préserve pas 
comme le montre la figure IV.12. 
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La troisième forme normale est importante, En effet, toute relation 
a au moins une décomposition en troisième forme normale telle que : 
1. la décomposition préserve les DF, 
2. la décomposition est sans perte. 


Cette décomposition peut ne pas être unique. Nous allons dans la 
suite étudier un algorithme permettant d’obtenir une telle décomposition. 


DF perdue par la décomposition 
V1, V2, V3 


Fig. IV.12. — DF perdue par la 
décomposition (V1, V2, V3} 





5.4. — Algorithme de décomposition en troisième forme normale 


Il existe donc au moins une décomposition en troisième forme nor- 
male préservant les DF et sans perte. Une telle décomposition peut étre 
produite par un algorithme ayant pour entrées l'ensemble des attributs 
ainsi que les DF (fig. IV.13). 





ATTRIBUTS 





ALGO. DE 
DÉCOM. 
POSITION 


RELATIONS DÉCOMPOSÉES EN 
TROISIEME FORME NORMALE 






Fig. IV.13. — Entrées et sorties d'un algorithme de décomposition en 3* forme normale 


Le principe d'un tel algorithme [Bernstein 76] consiste à partir 
d'une couverture minimale des DF, puis à éditer ensemble les attributs 
isolés dans une relation dont tous les attributs sont clés. Ensuite, on 
recherche le plus grand ensemble X d'attributs qui détermine d'autres 
attributs A,, Az, ... An (avec n > = 1), et l’on sort la relation (X, A, A; 
... An). Une telle relation de clé X est bien en 3* forme normale car X 
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détermine tous les autres attributs et il ne peut exister de dépendances 
transitives X — Ai — Aj du fait que l'on est parti d'une couverture mini- 
male (sinon, X — Aj ne serait pas dans cette couverture). Les DF X — 
An X — A, ..., X — An sont alors éliminées de la couverture minimale, 
ainsi que les attributs isolés (non source ou cible de DF) de l'ensemble 
des attributs. L'algorithme est ensuite appliqué récursivement (fig. 
IV.14). 


Procédure NORMALISER 3 (DF, ATTRIBUTS) ; 

C = «couverture minimale des DF » ; 

« Editer les attributs isolés dans C » ; 

RÉDUIRE (C) ; 

« Editer la relation composée de tous les attributs restants » ; 
fin. 


Procédure RÉDUIRE (C) ; 
Tant que « Une DF n'inclut pas tous les attributs » faire 
« Rechercher le plus grand ensemble d'attributs X 
tel que X — A, X — An»; 
« Editer la relation R < X, A,, .. An >»; 
« Eliminer les DF figurant dans R de C»; 
« Eliminer les attributs isolés » 
RÉDUIRE (C); 
fin tant que ; 
fin; 


Fig. IV.14. — Principe d'un algorithme de décomposition en troisième forme normale 


5.5. — Forme normale de BOYCE-CODD 


Considérons la relation 
VINS (CRU, PAYS, REGION) 


dont la clé est le couple « CRU - PAYS >, avec les dépendances fonc- 
tionnelles supposées : 


REGION — PAYS 
(CRU, PAYS) — REGION 


Cette relation est bien en troisième forme normale car aucun attribut 
non clé ne dépend d'une partie de la clé ou d'un attribut non clé. Cepen- 
dant, l'extension de cette relation représentée fig. IV.15 présente de 
nombreuses redondances. 
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VINS CRU PAYS RÉGION 
Chenas France Beaujolais 
Juliénas France Beaujolais 
Morgon France Beaujolais 
Brouilly France Beaujolais 
Chablis Etats-Unis Californie 














RÉGION 
Fig. IV.15. — Extension et DF de la relation VINS is © 


Afin d'éliminer ces types de redondances, Boyce et Codd ont intro- 
duit la forme normale qui porte leur nom (en abrégé BCNF) [Codd 74]. 


Notion 16 : Forme normale de Boyce-Codd (Boyce-Codd Normal form) 
Une relation est en BCNF si et seulement si les seules dépendances fonctionnelles élémen- 
taires sont celles dans lesquelles une clé détermine un attribut. 


Il a été montré que toute relation a une décomposition en BCNF qui 
est sans perte, Par contre, une décomposition en BCNF ne préserve en 
général pas les DF. Par exemple, la relation VINS pourra étre décompo- 
sée en deux relations : 


CRUS (CRU, REGION) 
REGIONS (REGION, PAYS) 


La DF (CRU, PAYS) — REGION est perdue ; cependant, il est possible 


de recomposer la relation initiale par jointure des deux relations sur l'at- 
tribut REGION. 


6. DÉPENDANCES MULTIVALUÉES 
ET QUATRIÈME FORME NORMALE 


6.1. — Dépendances multivaluées 


Nous avons introduit la notion de dépendance fonctionnelle qui 
nous a conduit à décomposer les relations en troisiéme forme normale et 


| 
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en forme normale de Boyce-Codd. Ceci est insuffisant pour éliminer les 
redondances et les anomalies de mises à jour. Considérons par exemple 
la relation : 


ÉTUDIANT (NE, COURS, SPORT) 


où NE est le numéro d'étudiant, COURS les cours suivis et SPORT les 
sports pratiqués. Une extension de cette relation est représentée figure 
IV.16. 











ÉTUDIANT NE COURS SPORT 
100 Bases de Données Tennis 
100 Bases de Données Football 
200 Bases de Données Vélo 
200 Math. Vélo 

















Fig. IV.16. = Relation en troisième forme normale avec redondances 


Il apparait clairement des redondances dans cette relation, et cependant, 
du fait de l'absence de dépendances fonctionnelles, elle est jusque-là non 
décomposable. 


L'exemple précédent montre l'insuffisance de la notion de dépen- 
dance fonctionnelle qui ne permet pas de saisir l'indépendance qui existe 
entre des attributs tels que COURS suivi et SPORT pratiqué. Pour cela, 
on généralise la notion de DF en introduisant celle de dépendance multi- 
valuée (DM) [Fagin 77, Zaniolo 81, Delobel 78]. 


Notion 17 : Dépendance Multivaluée (Multivalued dependency) 

Soit R (A1, A2, ... An) un schéma de relation et X et Y des sous-ensembles de A1, A2, ... 
An. On dit que X — Y (X multidétermine Y, ou il y a une dépendance multivaluée de Y 
sur X) si, étant données des valeurs de X il y a un ensemble de valeurs de Y associées et 
cet ensemble est indépendant des autres attributs Z = R — X = Y de la relation R. 


Une dépendance multivaluée caractérise donc une indépendance entre 
deux ensembles d'attributs (Y et Z) corrélés par un méme troisiéme X. 
Plus formellement, on a : 


(X =— Y) e f(xyz) et (xy'Z) € R = (xy'z) et (xyz) € R} 


où X, y, Z, y’, Z? désignent des occurrences des attributs X, Y, Z, Y, Z. 
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Il est à souligner que les DF sont des cas particuliers de DM. En 
effet : 
(X — Y) = (xyz) et (xy'z') E R = y = y] 
donc 
(X — Y) = ((xyz) et (xy'Z) € R = (xy'z) et (xyz) € R} 
Par suite : 


(X = Y) = (X =— Y). 


De maniére similaire aux dépendances fonctionnelles, il est possible 
d'effectuer des inférences à partir des dépendances multivaluées. Les 
axiomes d'inférence des DM sont les suivants, en considérant une rela- 
tion composée d'un ensemble d'attributs R [Beeri 78] : 

1. Complémentation : (X —— Y) = (X-—R-X- Y) 

2. Augmentation : (X —— Y) et (VE W) = (XW — YV) 
3. Transitivité : (X ——— Y) et (Y —— Z) => (X + Z - Y) 
Des règles additionnelles s'en déduisent, telle que celle d'union : 
4. Union : (X -e> Y) et (Y —— Z) = (X + YZ). 


A partir des axiomes précédents, il est possible d'introduire la 
notion de dépendance multivaluée élémentaire, ceci afin d'éliminer les 
dépendances déduites trivialement d'un ensemble de dépendances de 
base [Melkanoff 82], 


Notion 18 : Dépendance Multivaluée Elémentaire (Elementary multivalued dependency) 
Dépendance multivaluée X — Y d'une relation R telle que : 

1. Y n'est pas vide et est disjoint de X ; 

2. R ne contient pas une autre DM du type XY" telle que X' C Xet Y' c Y, 


Ainsi, une dépendance multivaluée élémentaire a, à la fois, un côté droit 
et un côté gauche minimum, comme une dépendance fonctionnelle élé- 
mentaire. 


Afin d'illustrer plus en détail, nous donnerons deux autres exemples 
de DM. Soit la relation : 


VOL (NV, AVION, PILOTE) 


où NV est un numéro de vol. On Suppose disposer d'un ensemble 
d'avions et d'un ensemble de pilotes. Tout pilote est conduit à piloter 
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tout avion sur n’importe quel vol. Ainsi, avion et pilote sont indépen- 
dants. D’où les deux DM élémentaires : 


NV — AVION 
NV ++ PILOTE. 


Soit encore la relation : 
PERSONNE (N° SS, PRÉNOM-ENFANT, N° VÉHICULE) 


Il est clair que l'on a les DM élémentaires : 


N° SS —— PRÉNOM-ENFANT 
N° SS ++ N° VÉHICULE. 


6.2. — Quatrième Forme Normale 


La quatrième forme normale est une généralisation de la forme nor- 
male de Boyce-Codd afin de décomposer les relations ayant des DM élé- 
mentaires. 


Notion 19 : Quatrième Forme Normale (Fourth normal form) 
Une relation est en quatrième forme normale si et seulement si les seules dépendances 
multivaluées élémentaires sont celles dans lesquelles une clé détermine un attribut. 


Du fait qu'une dépendance fonctionnelle est un cas particulier de dépen- 
dance multivaluée, il apparait qu'une relation en quatriéme forme nor- 
male est en forme normale de Boyce-Codd et donc en troisiéme forme 
normale. 


A titre d'exemple, la relation ETUDIANT (NE, COURS, SPORT) 
n'est pas en quatriéme forme normale : la clé est l'ensemble des attributs 
et il existe des DM élémentaires : 


NE — COURS 
NE -— SPORT 


entre des attributs participants à la clé. 


I] a été montré que toute relation a une décomposition (pas forcé- 
ment unique) en quatriéme forme normale qui est sans perte [Fagin TT]. 
Par exemple, la relation ETUDIANT peut étre décomposée en deux rela- 
tions (NE, COURS) et (NE, SPORT) qui sont bien en quatriéme forme 
normale. 
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7. DÉPENDANCES DE JOINTURES 
ET CINQUIÈME FORME NORMALE 


7.1. — Dépendances de jointures 


La notion de dépendance multivaluée a conduit à décomposer les 
relations en quatriéme forme normale. Est-ce suffisant pour éliminer les 
problémes de redondances et anomalies ? [Nicolas 78] et [Fagin 79] ont 
montré que non ! 

Considérons par exemple la relation représentée figure IV.17 ; cette 


relation modélise des vins bus par des buveurs, d'un cru donné et com- 
mandés à un producteur produisant ce cru. 





VINS, | BUVEUR CRU PRODUCTEUR 











Ronald Chablis Claude 
Ronald Chablis Nicolas 
Ronald Volnay Nicolas 
Jeffrey Chablis Nicolas 














Fig. IV.17. — Relation en quatrième forme normale avec redondance 


Cette relation est bien en quatriéme forme normale. En effet, il n'existe 
pas de dépendance multivaluée d'aprés l'extension représentée figure 
IV.17 : 

— BUVEUR => CRU est faux car par exemple le tuple (Ronald Vol- 
nay Claude) n'existe pas, 

— CRU -— PRODUCTEUR est faux car par exemple le tuple (Jeffrey 
Chablis Claude) n'existe pas, 

— PRODUCTEUR ~> BUVEUR est aussi faux car par exemple le 
tuple (Jeffrey Volnay Nicolas) n'existe pas. 


Autrement dit, si l'on considére les projections R1, R2, R3 de la relation 


VINS sur deux attributs représentées figure IV.18, on constate que l'on 
a: 


— VINS + R1 X R2, 
— VINS + R1 bd R3, 
— VINS # R2% R3. 
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Cependant, la relation représentée figure IV.17 présente bien des redon- 
dances : on apprend deux fois que Ronald boit du Chablis et que Nicolas 
produit du Chablis. Elle n'est cependant pas décomposable en deux rela- 
tions. 














Ri BUVEUR CRU R2 BUVEUR PRODUCTEUR 
Ronald Chablis Ronald Claude 
Ronald Volnay Ronald Nicolas 
Jeffrey Chablis Jeffrey Nicolas 





























R3 CRU `| PRODUCTEUR 

















Chablis Claude 
Chablis Nicolas 
Volnay Nicolas 





Fig. IV.18. — Trois projections de la relation VINS 


L'exemple précédent montre l'insuffisance de la notion de dépen- 
dance multivaluée pour éliminer les redondances. Le probléme vient du 
fait que jusqu'à présent, nous avons essayé de décomposer une relation 
seulement en deux relations ; ainsi, la notion de dépendance multivaluée 
capture la possibilité de décomposer une relation en deux ; la relation 
(XYZ) dans laquelle X —— Y est en effet décomposée en (XY) et (XZ) 
puisque Y et Z sont indépendants par rapport à X. Comme nous allons le 
voir, il existe des relations non décomposables en deux relations, mais 
décomposables en trois, quatre ou plus généralement n relations. Ce 
phénoméne a été découvert par [Aho 79] et [Nicolas 79]. 


A titre d'exemple de relation décomposable en trois relations et non 
décomposable en deux, supposons que la relation VINS obéisse à la 
contrainte d'intégrité assez plausible : 

« Tout buveur ayant bu un cru et ayant commandé à un producteur 
produisant ce cru, a aussi commandé ce cru à ce producteur ». 


Cette contrainte s'écrit plus formellement : 


(b,c) € R1 et (b, p) € R2 et (c, p € R3 = (b, c, p € R. 
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Dans ce cas, R sera la jointure de Ri, R2 et R3 : 
R = R1% R2 bx R3 


Cette contrainte est bien vérifiée par l'extension de la relation VINS 
représentée figure IV.17. 


Plus généralement, [Rissanen 78] a introduit la notion de dépen- 
dance de jointure (DJ) afin de décomposer des relations en plusieurs : 


Notion 20 : Dépendance de jointure (Join dependency) 

Soit R (A1, A2 ... An) un schéma de relation et X1, X2, ... Xm des sous-ensembles de 
(A1, A2, ... An]. On dit qu'il existe une dépendance de jointure 

* [X1, X2, ... Xm] si R est la jointure de ses projections sur X1, X2 ... Xm, c'est-à-dire 
si: 

R = IIX1 (R) DIX 2 (R)bd ... DXLTIXm (R). 


Par exemple, la relation VINS obéit à la dépendance de jointure : 


* (BUVEUR CRU, BUVEUR PRODUCTEUR, CRU PRODUCTEUR) 


Elle est donc décomposable en trois relations R1, R2, R3. 


Les dépendances multivaluées sont bien sür des cas particuliers de 
dépendances de jointures. En effet, une relation R (X,Y,Z) vérifiant la 
dépendance multivaluée X — Y (et donc X ~-e Z) satisfait la dépen- 
dance de jointure : 


* (XY, XZ). 
7.2. — Cinquième forme normale 


La cinquième forme normale est une généralisation de la quatrième 
à partir de la notion de dépendance de jointure. Sa définition nécessite 
d’étudier les dépendances de jointures induites par la connaissance des 
clés d’une relation. 


A titre d'exemple, soit une relation R (A1, A2, A3, A4) ayant par 
exemple A1 et A2 pour clés candidates. Alors, il est possible de décom- 
poser sans perte cette relation en * (A1A2, A1A3, A1A4} et aussi en 
* {AIA2, A2A3, A2AA|, etc. La définition des clés d'une relation impli- 
que donc la connaissance de dépendances de jointures. 


Pius généralement, l'algorithme représenté figure IV.19 permet de 
tester si une dépendance de jointure DJ est impliquée par un ensemble de 
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clés K d’une relation R (X). La procédure IMPLIQUE répond vrai si oui 
et faux si non. Cet algorithme esi dû à [Fagin 79]. 


Fonction IMPLIQUE (K, DJ) ; 
(DJ est une dépendance de jointure * (X1, ... Xm]; 
K est un ensemble de clés K1 — X, ... Kr — X) 
S: = (X1, ... Xm] 
Tant que «il existe Ki, Y € S et Z € S» tels que Ki € Y n Z faire 
«enlever Y et Z de S»; 
« ajouter Y U Z dans S »; 
fin tant-que ; 
siXes alors IMPLIQUE : 
sinon IMPLIQUE : 


fin IMPLIQUE ; 


vrai ; 
faux ; 





Fig. 19. — Algorithme testant si un ensemble K de clés implique une dépendance 
de jointure DJ. 


Il nous est maintenant possible de définir la cinquiéme forme nor- 
male. 


Notion 21 : Cinquième Forme Normale (Fifth normal form) 
Une relation R est en cinquiéme forme normale si et seulement si toute dépendance de 
jointure est impliquée par les clés candidates de R. 


Ainsi la relation VINS représentée figure IV.17 n'est pas en 5* forme 
normale puisque la seule clé candidate (BUVEUR, CRU, PRODUC- 
TEUR) n'implique pas la DJ * (BUVEUR CRU, CRU PRODUCTEUR, 
BUVEUR PRODUCTEUR |. Elle doit donc être décomposée en ces trois 
relations afin d'éviter les anomalies de mise à jour. 


En conclusion, [Fagin 79] a démontré le résultat essentiel suivant. 
Toute relation en 5° forme normale ne peut plus être décomposée sans 
perte d'informations (excepté par les décompositions basées sur les clés 
qui sont sans intérêt) si l’on ne considère que la décomposition par pro- 
jection et la recomposition par jointure. La 5° forme normale est donc 
un point final à la décomposition par projection-jointure. Voilà pour- 
quoi Fagin propose d’appeler cette forme « forme normale de projec- 
tion-jointure » (JD/NF). 
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8. CONCLUSION 


Dans ce chapitre, nous avons présenté les concepts de base du 
modèle relationnel ainsi que la théorie de la normalisation. Le modèle 
relationnel connaît un succès certain en raison de sa simplicité et aussi 
des langages de manipulation de données associés qui sont nombreux et 
puissants comme nous le verrons dans le chapitre suivant. 


Cependant, le modéle est souvent critiqué en raison du petit nombre 
de concepts qui ne lui permettent pas de bien capturer la sémantique des 
applications. Aussi, CODD a proposé un modéle étendu avec des opéra- 
teurs capables de gérer les valeurs nulles, des entités composées par abs- 
tractions successives, des associations et des événements [Codd 79]. Ce 
modéle perd malheureusement la simplicité du modéle relationnel. 


D'un autre côté, la théorie de la normalisation reste une théorie pra- 
tiquement peu utilisée. Son application effective à la conception des 
bases de données nécessiterait sans doute de lever les hypothéses trop res- 
trictives d'unicité de la relation universelle [Kent 81] et nécessiterait aussi 
l'extension de la théorie à d'autres opérateurs que la projection et la 
jointure, par exemple à l'union et à l'opération inverse d'éclatement 
[Fagin 79]. 


Un modéle permettant de capturer la dynamique des données pour- 
rait de plus compléter le modéle [Rolland 82]. 
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V. LES LANGAGES DE MANIPULATION 
DE DONNÉES RELATIONNELLES 


1. INTRODUCTION 


Un langage de manipulation de données se compose d’un ensemble 
de commandes permettant d'interroger une base de données et d'un 
ensemble de commandes permettant de la modifier. La modification 
inclut l'insertion, la mise à jour et la suppression. Le langage de modifi- 
cation est en général complémentaire du langage d'interrogation sur 
lequel les concepteurs de systémes de bases de données ont souvent fait 
porter l'essentiel de leurs efforts. 


Un langage de manipulation de données n'est pas suffisant à lui 
seul : il doit être incorporable dans un langage de programmation classi- 
que appelé langage hóte afin de réaliser des transactions programmées. 
Ainsi la plupart des SGBD dispose d'un langage de manipulation de 
données externe conversationnel et propose une intégration de ce lan- 
gage dans un langage hóte. 


Un des grands mérites du modéle relationnel qui justifie sans doute 
son succés est d'avoir motivé le développement de multiples langages 
d'interrogation assertionnels, c'est-à-dire permettant de définir les don- 
nées que l'on souhaite visualiser sans dire comment les accéder. La plu- 
part de ces langages sont basés sur un modèle théorique. 


On peut distinguer trois grandes classes de langages [Pirotte 78]. Les 
langages algébriques sont, plus ou moins, basés sur l'algébre relation- 
nelle de CODD [Codd 70, Codd 72], et permettent d'appliquer des 
séquences d'opérateurs spéciaux aux relations. Le langage d'IBM 
SEQUEL [Chamberlin 76] commercialisé sous le nom SQL [1BM 81] 
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représente l'ultime aboutissement de ce type de langage. Le calcul rela- 
tionnel de tuples et ses dérivés sont construits à partir de la logique des 
prédicats [Gallaire 79], en associant à chaque variable des formules logi- 
ques les tuples d'une relation. Le langage QUEL du système INGRES 
[Zook 77] représente une réalisation pratique et élégante de ce type de 
langage. Le calcul relationnel de domaines est aussi construit à partir de 
la logique des prédicats, mais en faisant varier les variables sur les domai- 
nes des relations. Le langage DRC [Pirotte 82] est trés représentatif de ce 
type de langage qui fut implanté dans le systéme SYNTEX [Artaud 74]. 
On peut également considérer que QBE d'IBM est un dérivé bi- 
dimensionnel de ce type de langage [Zloof 77, IBM 78]. 


Dans ce chapitre, nous allons étudier successivement ces trois types 
de langages. Les fondements de chacune des classes, ainsi qu'un repré- 
sentant typique sont présentés. Nous terminerons cette partie par l'étude 
du langage QBE, puis par quelques considérations sur l'utilisation des 
langages de manipulation dans les langages de programmation classiques. 


2. L'ALGÈBRE RELATIONNELLE 


L'algébre relationnelle a été inventée par E. COOD comme une col- 
lection d'opérations formelles sur les relations [Codd 70, Codd 72]. Nous 
avons déjà introduit les opérations de projection et jointure. Nous allons 
maintenant étudier plus en détails toutes les opérations de l'algébre 
relationnelle. 


2.1. — Opérations de base 


Il est possible de distinguer les opérations suivant plusieurs critères. 
Tout d'abord, nous allons introduire un ensemble d'opérations qui per- 
mettent de déduire les autres, appelées ici opérations de base. Plusieurs 
opérations de base sont possibles et notre choix est arbitraire. L'ensem- 
ble choisi se compose d'opérations binaires ensemblistes (opérant sur deux 
relations) et d'opérations unaires spécifiques. 


2.1.1. — Opérations ensemblistes 


Les opérations ensemblistes de base sont des opérations binaires, c'est- 
à-dire qui, à partir de deux relations, en construit une troisième. Ce sont 
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l'union, la différence et le produit cartésien que nous allons définir plus 
précisément. 


L'union de deux relations R et S de méme schéma est une relation T de même schéma 
contenant l'ensemble des tuples appartenant à R ou S ou aux deux relations. 


[no 1 : Union (Union) 
Plusieurs notations ont été introduites dans la littérature pour cette opé- 
ration : 

+ T=RUS 
e T = UNION (R, S) 
et nous utilisons essentiellement la notation graphique représentée figure 
V.1. 


Fig. V.1, — Représentation 
graphique de T = RUS 


A titre d'exemple, nous utilisons deux relations VINS-1 et VINS-2 de méme 
schéma VINS (Numéro, Cru, Millésime, Degré) dont les occurrences et 
l'union VINS-3 = VINS-1 U VINS-2 sont représentés figure V.2. 

















T T 

| VINS-1 Numéro | Cru Millésime Degré 
100 Chablis 1974 12 
110 Mercurey 1978 13 
120 Macon il 7 | n 

T T 

| VINS-2 Numéro Cru Millésime Degré 
100 Chablis 1974 | 12 
200 Sancerre 1979 11 
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VINS-3 Numéro Cru Millésime Degré | 
100 Chablis 1974 12 
110 Mercurey 1978 13 
120 Macon 1977 12 
200 Sancerre 1979 11 














Fig. V.2. — VINS-3 est l'union de VINS-1 et VINS-2 


| Notion 2 : Différence (Difference) 
La différence de deux relations R et $ de même schéma (dans l'ordre R — S) est une rela- 
tion T de même schéma contenant les tuples appartenant à R et n’apparténant pas à S. 


Des notations possibles sont : 


*T=R-S 
* T = MINUS (R, S) 


Nous utilisons la notation graphique représentée figure V.3. 


Fig. V.3. = Représentation graphique 
R S deT =R - $ 


A titre d'exemple, la relation VINS-4 représentée figure V.4 est la diffé- 
rence des relations VINS-1 — VINS-2, représentées figure V.2. 

















VINS-4 Numéro | Cru | Millésime Degré | 
110 Mercurey 1978 13 
120 Macon 1977 12 





Fig. V.4. — Relation différence de VINS-1 - VINS-2 
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Notion 3 : Produit Cartésien (Cartesian Product) 
Le produit cartésien de deux relations (de schéma quelconque) R et S, est une relation 
ayant pour attributs la concaténation de ceux de R et S et dont les tuples sont toutes les 
concaténations d'un tuple de R à un tuple de S. 


Des notations possibles pour cette opération sont : 


e RXS 
* PRODUCT (R, S) 
* TIMES (R, S) 


Nous utilisons la notation graphique représentée figure V.5. 
T 


Fig. V.5. — Représentation 
graphique de T = R x S R S 


A titre d'exemple, la relation VIGNOBLE représentée figure V.6 est le 
produit cartésien des deux relations VINS-5 et VITICULTEURS de la 


méme figure. 







Millésime 


Mercurey 
Macon 









































VITICULTEURS Nom Ville Région 
IL a 
Nicolas Pouilly Bourgogne 
Martin Bordeaux | Bordelais 
— 4 
"eel Numéro Cru Millésime | Degré | Nom Ville Région 
110 Mercurey 1978 13 Nicolas | Pouilly | Bourgogne 
110 Mercurey 1978 13 Martin | Bordeaux | Bordelais 
120 Macon |. 1977 12 |Nicolas | Pouilly | Bourgogne 
120 Macon 1977 12 Martin | Bordeaux | Bordelais 











Fig. V.6. — Exemple de produit cartésien 
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2.1.2. — Opérations unaires 


Deux opérations unaires combinées avec les opérations précédentes 
permettent de construire toutes les opérations de l’algèbre relationnelle. 
Elles sont appelées respectivement projection et restriction. 


Notion 4 : Projection (Projection) 

La projection d'une relation R de schéma R (A,, Az, ... An) sur les attributs Ai,, Aio, ... 
Ai, (avec ij + i, et p < n) est une relation R' de schéma R’ (Ai,, Ais, ... Ai.) dont 
les tuples sont obtenus par élimination des valeurs des attributs de R n'apparte- 
nant pas à R' et par suppression des tuples en double 


Les notations suivantes sont utilisées pour cette opération : 
* IT Ai, Ai, ... Ai, (R) 
* R (Ah, Ai, ... Aij] 
e PROJECT (R/AÏ, Ai, ... Ai.) 


Nous utilisons essentiellement la notation graphique représentée figure V.7. 





AR 
Aiq eise Alp 
Á Fig. V.7. — Représentation graphique 
de la projection de R 
R sur les attributs Ai; ... Aip 


A titre d'exemple, la relation VINS-7 est la projection de la relation 
VINS-6 représentée figure V.8 sur les attributs Millésime et Degré. 


Afin de définir la dernière opération unaire de base, nous introdui- 
rons tout d'abord le concept de formule de qualification (ou simplement 
qualification, encore appelée critére de sélection) que nous généralise- 
rons plus tard à la notion de formule bien formée. Pour simplifier et 
dans le but d'éviter les problémes de parenthésage (ou de priorité), nous 
nous restreindrons aux formules de qualification conjonctives, c'est-à- 
dire sans « ou », celui-ci pouvant étre réalisé avec l'union. Une formule 
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| VINS-6 Numéro Cru Millésime Degré 
100 Chablis 1974 12 
120 Macon 1977 12 
140 Sancerre 1977 12 
160 Mercurey 1976 13 
d 








| VINS-7 Millésime Degré 








1974 12 
1977 12 
Fig. V.8. — Exemple 1976 13 


de projection 





de qualification conjonctive est une conjonction (ET noté A) de formules 
de qualifications atomiques. Une formule de qualification atomique est 
formée d'un nom d'attribut relié à une constante par un opérateur de 
comparaison © choisi parmi (<, =, >, x, >, #}. Une formule de 
qualification atomique est donc du type Ai © C, où Ai est un attribut et 
C une constante. Plus généralement, une formule de qualification 
conjonctive Q est du type : 


Ai, €, C, A Ai, 92 C; A ... A Ai, Op Cp 
Par exemple : 
Cru = « Chablis » A degré > 13 


est une qualification conjonctive. A partir de la notion de qualification, 
il est possible de définir la restriction. 


Notion 5 : Restriction (Restriction) 
La restriction de la relation R par une qualification Q est une relation R' de màme 
Schéma dont les tuples sont ceux de R satisfaisant la qualification Q. 


Les notations suivantes sont utilisées pour la restriction : 


* op (R) 

e R [Q] 

e RESTRICT (R/Q) 
e SELECT (R/Q) 


ainsi que la notation graphique représentée figure V.9. 


A titre d'exemple, la restriction de la relation VINS-6 représentée figure 
V.8 par la qualification Millésime = 1977 est représentée figure V.10 
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{relation VINS-8). La restriction de cette même relation par la qualifica- 
tion Millésime = 1977 À Degré > 13 est vide. 











R' 
R Fig. V.9. — Restriction de la relation R 
par la qualification Q 
| VINS-8 | Numéro Cru Millésime Degré 
120 Macon 1977 12 
140 Sancerre 1977 12 








Fig. V.10. — Exemple de restriction de'la relation VINS-6 par la qualification 
Millésime = 1977 


2.2. — Opérations additionnelles 


Ces opérations se déduisent des précédentes et sont donc redondan- 
tes. Cependant, elles sont essentielles pour la réalisation pratique des 
systèmes relationnels : en effet, le produit cartésien étant une opération 
très coûteuse, on préfère réaliser l'opération de jointure que nous allons 
maintenant définir. 


Cette définition nécessite l’introduction de qualifications permet- 
tant de comparer des attributs différents (ou le même attribut) d’une 
relation R (A1, A2, ... An) : nous parlerons alors de qualification multi- 
attributs, du type Ai 6, Aj ou plus généralement Ai, 6, Aj; À Ai; 6, Aj; 
... À Ai, Ok Aj, . Soient alors R (A1, A2, ... An) et S (B1, B2, ... Bp) 
deux relations et Q une qualification multi-attributs comparant des attri- 
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buts de R à ceux de S, par exemple Ai = Bj, ou bien Ai = Bj A Ak = 
Bq, ou encore Ai = Bj À Ak > Bq, etc. 


Notion 6 . Jointure (Join) E 
La jointure de deux relations R et S selon une qualification multi-attributs Q est 
l'ensemble des tuples du produit cartésien R x S satisfaisant la qualification Q. 


Cette opération essentielle pour la réalisation de systèmes relationnels est 
notée : 
e RXS 
Q 
e JOIN (R, S/Q) 
ou encore comme une restriction du produit cartésien : 


e RXS[Q] 


La notation graphique que nous utilisons est représentée figure V.11. 


Fig. V.11. — Représentation 
graphique de la jointure R s 


Pour illustrer, la figure V.12 présente la jointure VINS-9 X VIT des rela- 
tions VINS-9 et VITICULTEURS selon la qualification Cru = Ville. 

















Numéro Cru Millésime 
120 Macon 1977 12 
200 Saumur 1977 12 
210 Saumur 1979 14 
VITICULTEURS Nom Ville Région 
Nicolas Pouilly Bourgogne 
Félix Macon Bourgogne 


Pierre Saumur Loire 
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VINS-9 








Numéro! Cru vie pas Ville Région | 








M VIT Nom 
120 Macon 1977 12 Félix | Macon | Bourgogne 
200 Saumur 1977 12 |Pierre | Saumur Loire 
210 {Saumur 1979 14 | Pierre | Saumur Loire 








Fig. V.12. — Exemple de jointure 


On distingue divers cas particuliers de jointure : 


— l'équijointure de R et S sur les attributs Ai et Bj est la jointure selon 
la qualification Ai — Bj (équi pour opérateur —), 

— la O jointure de R et S sur les attributs Ai et Bj est la jointure selon la 
qualification Ai O Bj, 

= l'autojointure de R selon l'attribut Ai est la jointure de R avec elle- 
méme selon la qualification Ai = Ai que l’on peut noter JOIN (R, R/ Ai 
= Ai). 

— la jointure naturelle de R et S, simplement notée R M S est l'équijoin- 
ture de R et S sur tous les attributs ayant m&me nom dans R et S, suivie 
de la projection qui permet de conserver un seul de ces attributs égaux de 
méme nom ; par exemple, la figure V.13 illustre la jointure naturelle des 
relations VINS-9 et PRIX. 


Macon 
Saumur 
Saumur 

























VINS-9 P —M— 4 a 

NX PRIX Numéro Cru Millésime Degré | Coût 
120 Macon 1977 12 30 
200 Saumur 1977 12 52 
210 Saumur 1979 14 37 





Fig. V.13. — Jointure naturelle des relations VINS-9 et PRIX 
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Une autre opération importante dérivée de la jointure est la semi- 
jointure [Bernstein 81]. La semi-jointure de la relation R par la relation 
S selon une qualification multi-attributs Q est l'ensemble des tuples de R 
participant à la jointure de R et S selon la qualification Q. Cette opéra- 
tion notée R'X S est importante afin d'optimiser l'évaluation des ques- 
tions relationnelles. 


L'intersection est une opération ensembliste plus simple qui s'appa- 
rente cependant à la jointure. 


L'intersection de deux relations R et S de même schéma est une relation T de 


[le 7 : Intersection (Intersection) 
même schéma contenant les tuples appartenant à la fois à R et S. 


L'intersection de R et S est notée selon les cas : 


e RNS 
e INTERSECT (R, $) 


Il est possible de l’obtenir à partir de la différence à l’aide d’une des for- 
mules : 


RNS =R - (R = S) 
RNS =S - (S - P) 


La notation graphique de l'intersection est représentée figure V.14. 
T 


Fig. V.14. — Représentation 
graphique de l'intersection R s 


La dernière opération relationnelle que nous introduirons est la 
division. Cette opération permet de rechercher l'ensemble de tous les 
sous-tuples satisfaisants une sous-relation dans une relation. 


Notion 8 : Division (Division) 

Le quotient de la relation R de schéma R (A,, A, ... A„) par la sous-relation S de 
schéma S (Ap... ... An) est la relation Q de schéma Q (A; A; ... Ap) formée de 
tous les tuples qui concaténés à chacun des tuples de S donne toujours un tuple 


de R. 
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Désignons par a; une valeur quelconque de l’attribut Ai. Le quotient 
Q de R par S peut être défini par : 


Q = {(a, 85 ... a) / V (85,5. Ap) € S, (8182 a, Apii o aj e R] 


Des notations possibles pour la division sont : 


e R-S 
e DIVISION (R, S) 


ainsi que la représentation graphique de la figure V.15. 


La division peut être obtenue à partir de la différence, le produit carté- 
sien et la projection comme suit : 


— R +S =T - Uavec 
— T = R [Ay A2... A) 
— U = ((TX S) = R) fA, Az... Ap} 


Fig. V.15. — Représentation 
R s de la division 


Soient par exemple les relations VINS-10 et TYPE représentées figure 
V.16. La relation CRU est le quotient de VINS-10 par TYPE. 








| VINS-10 | Cru Millésime Degré 
Macon 1977 12 
Macon 1979 14 
Macon 1980 12 
Saumur 1977 12 
Saumur 1979 14 
Chablis 1979 14 
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| TYPE Millésime Degré CRU CRU 
1977 12 Macon 
1979 14 Saumur 











Fig. V.16. — Exemple de division 


2.3. — Composition d'opérations 








Avec les opérations de base successivement enchaînées sur des rela- 
tions, il est possible de composer la plupart des questions que l'on peut 
poser à une base de données relationnelle. Afin de simplifier l'expression 
des questions, on utilise en général la jointure, en place du produit carté- 
sien suivi d'une restriction. Les questions peuvent donc &tre exprimées à 
l'aide de successions des opérations : UNION, DIFFÉRENCE, JOIN- 
TURE, RESTRICTION et PROJECTION. La représentation graphique 
de ces opérations permet de composer des arbres d'opérations relation- 


nelles [Smith 75]. 






Nom, 
Adresse, 
Degré 










Quantité 
>10 







Cru =«Chablis», 
Millésime = 1976 


Fig. V.17. — Exemple 
d'arbre permettant 
d'exprimer une question ABUS VINS 








BUVEURS 
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A titre d'exemple, soit la base composée des relations : 


VINS (NV, CRU, MILLÉSIME, DEGRÉ) 
BUVEURS (NB, NOM, ADRESSE) 
ABUS (NB, NV, QUANTITÉ) 


où NV et NB désigne respectivement des numéros de vins et de buveurs. 


La question : « Nom et Adresse des buveurs ayant bu plus de 10 bouteil- 
les de Chablis 1976 et degré de ce vin », peut &tre exprimée à l'aide de 
l'arbre représenté figure V.17. Cet arbre n'est pas le seul possible pour 
cette question comme nous le verrons au chapitre IX. 


3. LE LANGAGE SQL 


Le langage SQL [IBM 81] est une évolution commercialisée par 
IBM du langage SEQUEL [Chamberlin 76] initialement développé à 
IBM San-José comme un langage de recherche (SEQUEL fut lui-méme 
dérivé de SQUARE [Boyce 75]). Ce langage peut être perçu comme une 
expression agréable et très complète de séquences d'opérations relation- 
nelles. 


Nous illustrerons SQL sur la base de données composée des trois rela- 
tions vues ci-dessus : 


VINS (NV, CRU, MILLÉSIME, DEGRÉ) 
BUVEURS (NB, NOM, ADRESSE) 
ABUS (NB, NV, QUANTITÉ) 


où NB et NV désignent respectivement des numéros de vins et de buveurs 
et la relation ABUS associe un vin au buveur qui l'a bu en quantité indi- 
quée par l'attribut QUANTITÉ. 


3.1. — Expression des projections 


Rappelons qu'une projection effectue l'extraction de colonnes 
(attributs) spécifiées d'une relation puis élimine les tuples en double. Une 
projection s'exprime à l'aide du langage SQL par la clause : 

SELECT liste d'attributs 

FROM nom de relation 
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SQL n'élimine pas les doubles à moins que ceci soit explicitement 
demandé par le mot clé UNIQUE. 


Par exemple, obtenir les vins et millésimes de tous les vins avec double 
s'exprime : 


SELECT CRU, MILLÉSIME 
FROM VINS 


alors que la méme question sans double s'exprime : 


SELECT UNIQUE CRU, MILLÉSIME 
FROM VINS 


3.2. — Expression des sélections 


Une sélection est une combinaison d'une restriction suivie d'une 
projection. Une restriction s'exprime par un bloc du type : 


SELECT * 
FROM nom de relation 
WHERE qualification 





La combinaison avec une projection s'effectue en remplaçant * (qui 
désigne tous les attributs) par la liste d'attributs de projection. A titre 
d'exemple la restriction de la relation VINS par la qualification Millé- 
sime = 1977 A Degré > 13 s'effectue par la question : 


SELECT  * 

FROM VINS 

WHERE MILLESIME = 1977 
ND DEGRE > 13 





Si l’on désire seulement les vins et numéros des vins de millésime 1977 et 
de degré supérieur à 13, on écrira : 


SELECT CRU, NV 

FROM VINS 

WHERE MILLESIME = 1977 
AND DEGRÉ » 13 





De maniére plus générale, la condition suivant la clause WHERE peut 
inclure les opérateurs de comparaison =, 1 = (différent), >, > =, < 
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et < = pour composer des qualifications atomiques. Les qualifications 
sont obtenues à l’aide des opérateurs booléens AND (et), OR (ou), NOT 
(négation) et de parenthèses éventuelles pour indiquer l’ordre d’évalua- 
tion. 


Il est également possible de trier les résultats suivant l’ordre ascen- 
dant (mot clé ASC) ou descendant (mot clé DESC) d’un ou plusieurs 
attributs. Ceci s'effectue en ajoutant une clause du type (les [ ] signifient 
paramètre optionnel) : 


ORDER BY nom d'attribut [ordre] [, nom d'attribut [ordre]]... 


Par exemple, l'obtention des crus et numéros de vins de millésime 1977 et 
de degré supérieur à 13 triés par ordre alphabétique croissant sur noms 
de cru et décroissant sur numéros de vins s'effectue à l'aide de la ques- 
tion : 


SELECT CRU, NV 
FROM VINS 

WHERE MILLESIME = 1977 
AND DEGRÉ > 13 
ORDER BY CRU ASC, NV DESC 








3.3. — Expression des jointures 

Un cas particulier simple de jointure sans qualification est le produit 
cartésien. Celui-ci s'exprime trés simplement en incluant plusieurs rela- 
tions dans la clause FROM. Par exemple, le produit cartésien des rela- 
tions VINS et ABUS se calcule à l'aide de la question : 


SELECT >» 
FROM VINS, ABUS 


La jointure avec qualification peut s'exprimer de plusieurs manié- 
res. Une première expression naturelle est la restriction du produit carté- 
sien. Par exemple, la jointure de VINS et ABUS sur l'attribut numéro de 
vins (NV) peut s'écrire : 


SELECT  * 


FROM VINS, ABUS 
WHERE  VINS.NV = ABUS.NV 


mais la jointure peut aussi être exprimée d'une manière plus procédurale 
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avec des blocs imbriqués reliés par l'opérateur IN : 
SELECT CRU 





FROM VINS 

WHERE  NVIN 
(SELECT NV 
FROM ABUS) 


IN peut être vu comme l'opérateur ensembliste d'appartenance ( € ) ; par 
exemple, dans la question précédente, on exprime le fait que le numéro 
de vins des crus cherchés doit appartenir à la liste des numéros de vins 
dans la relation ABUS. A souligner que les attributs résultats doivent 
appartenir aux relations citées dans le bloc le plus externe. 


On peut évidemment combiner jointure, restriction et projection. Il 
est également possible d'imbriquer des blocs SELECT... FROM... 
WHERE... à plusieurs niveaux. Ainsi la question « Noms des buveurs 
ayant bu du Chablis » peut se formuler de l'une des maniéres suivantes 
(d'autres sont possibles) : 


(€ SELECT UNIQUE NOM 
FROM  BUVEURS, VINS, ABUS 
WHERE  BUVEURS.NB = ABUS.NB 
AND ABUS.NV = VINS.NV 
AND VINS.CRU = « Chablis » 





A noter la nécessité du mot clé UNIQUE afin d'éliminer les doubles résul- 
tant éventuellement des jointures. 


(2 SELECT | UNIQUE NOM 
FROM BUVEURS 
WHERE  NBIN 
(SELECT NB 
FROM ABUS, VINS 
WHERE ABUS.NV = VINS.NV 
AND VINS.CRU = « Chablis ») 





(3 SELECT UNIQUE NOM 
FROM  BUVEURS 
WHERE  NBIN 
(SELECT NB 
FROM ABUS 
WHERE NV IN 
(SELECT NV 
FROM VINS 
WHERE CRU = « Chablis ») 





110 


Bases de données 


Afin de faciliter les imbrications de blocs, il est possible de référen- 
cer dans un bloc interne une relation d'un bloc externe ; on parle alors de 
référence interbloc. Ainsi, la question précédente peut encore s'écrire : 


(4) SELECT 
FROM 
WHERE 





UNIQUE NOM 

BUVEURS 

« Chablis » IN 

(SELECT CRU 

FROM VINS, ABUS 

WHERE VINS.NV = ABUS.NV 
AND ABUS.NB = BUVEURS.NB) 


* 








3.4. — Autres possibilités d'interrogation 


SQL permet également d'exprimer l'opération d'union. Par exem- 
ple, l'obtention des crus de degré supérieur à 13 ou de millésime 1977 
peut s'effectuer par : 











Enfin, au-delà de l’algèbre relationnelle, des possibilités de calcul de i 


CRU 
VINS | 
DEGRÉ » 13 


CRU 
VINS 
MILLESIME = 1977 


fonctions existent. Les fonctions implantées sont : 





nombre de valeurs 
somme des valeurs 
moyenne des valeurs 
valeur maximum 
valeur minimum 


Hdl AH ug 


Les fonctions peuvent être utilisées dans la clause SELECT, par exemple 
pour calculer le degré moyen des « Chablis » : 


SELECT 


FROM 
WHERE 





AVG (DEGRE) 
VINS 
CRU = « Chablis » 
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mais aussi pour exprimer une qualification de recherche à l’aide d’une 
clause spéciale : 

GROUP BY liste d'attributs HAVING qualification avec fonction 
Par exemple, la recherche de tous les numéros de vins bus par plus de 100 
buveurs s'effectuera à l'aide de la question : 


SELECT NV 
FROM ABUS 
GROUP BY NV HAVING COUNT (*) > 100 








SQL fournit également d'autres clauses et mots clés tels que ALL, 
ANY, EXISTS qui permettent de distinguer les cas où l’on recherche un 
élément quelconque des cas où l’on recherche tous les éléments. Nous 
étudierons ces variantes pour d’autres langages plus formalisés. 


3.5. — Mises à jour 


SQL offre trois opérateurs de mise à jour : INSERT (insérer), 
DELETE (supprimer) et UPDATE (modifier). Nous illustrerons chacun 
d’eux par un exemple. 


a) Insérer le tuple (200, Chablis, 1977, 14) dans la relation VINS. 


INSERT — INTO VINS 
< 200, « Chablis », 1977, 14 > 


b) Supprimer tous les vins bus par MARTIN. 


DELETE VINS 

WHERE « MARTIN » IN 
(SELECT NOM 
FROM BUVEURS, ABUS 
WHERE VINS.NV = ABUS.NV 


AND ABUS.NB = BUVEURS.NB) 











c) Mettre la quantité bue à O pour tous les buveurs d'adresse TOKYO. 


UPDATE ABUS | 

SET QUANTITÉ = 0 

WHERE «TOKYO» = 
(SELECT ADRESSE 
FROM BUVEURS 
WHERE NB = ABUS.NB) 
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4. RAPPELS SUR LE CALCUL DE PRÉDICATS 
DU PREMIER ORDRE 


Le calcul de prédicats du premier ordre est un système de logique 
sur lequel sont basés les principaux langages de manipulation de données 
relationnels. Voilà pourquoi nous allons rappeler dans ce paragraphe 
quelques notions sur le calcul de prédicats, en particulier celle de formule 
bien formée [Nilsson 71]. 


4.1. — Syntaxe 


La syntaxe du calcul de prédicats du premier ordre comporte : 
1. La spécification d’un alphabet de symboles 
2. La définition d’expressions utiles appelées formules bien formées (en 
abrégé formules) qui peuvent être construites à partir de ces symboles. 
L'alphabet de base comporte l’ensemble des symboles suivants : 


Les parenthéses ( ) 

Les symboles logiques = (IMPLIQUE) et 1 (NON) 

Un ensemble de constantes notées a, b, c... 

Un ensemble de variables notées X, Y, Z.. . 

. Un ensemble de prédicats à m arguments notés P, Q, R... 
6. Un ensemble de fonctions à n arguments notées f, g, h... 


CA RU D — 


Des formules peuvent être construites à l'aide de cet alphabet, è par- 
tir de termes et de formules atomiques. Un terme est défini récursive- 
ment comme une constante, une variable ou une fonction dont les argu- 
ments sont eux-mêmes des termes. Une formule atomique est définie 
comme un prédicat à m arguments, dont les arguments sont des termes. 
Enfin, une formule bien formée ou simplement formule, est définie 
récursivement comme suit : 


a) Une formule atomique est une formule bien formée 

b) Si A est une formule bien formée, alors 7 A est une formule bien for- 
mée 

c) Si A et B sont des formules bien formées, alors A = B est une formule 
bien formée. 


Ainsi, quelques exemples de formules bien formées sont : 


7P (a, g (a, b, a)) 
P (a, b) = (1 Q(o) 
7P (a) = Q (f(a) 
( 5 (P (a) = P (b) = P (b) 
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La première addition qui est généralement faite à l'alphabet est celle 
des symboles logiques À (ET) et V (OU), qui permettent une notation 
plus naturelle et plus abrégée des formules composées de 7 et =, Soient 
A et B deux formules bien formées. Alors les expressions A B et A V B 
sont définies comme suit : 


AAB= 7 (A = 7B) 
AVB=(7A) = B 


Après cette addition, il n'est pas nécessaire de conserver les quatre 
symboles 1 , =, V, A. En général, les formules bien formées des bases 
de données sont construites à l'aide des trois symboles 7 , A, V. 


4.2. — Sémantique 


Dans le but de donner une signification aux formules, il est néces- 
saire de les interpréter comme des assertions sur un domaine de discours. 
Dans les bases de données relationnelles, le domaine de discours est 
l’ensemble des occurrences possibles de la base, c’est-à-dire l’ensemble 
des domaines des attributs des relations. La spécification du domaine de 
discours D conduit à préciser une interprétation des formules bien for- 
mées, comme suit : 


a) Toute constante doit être associée à un élément particulier de D. 

b) Toute variable doit être associée à un ensemble d'éléments de D. 

c) Tout prédicat doit être associé à des relations particulières entre les 
éléments de D. 

d) Toute fonction doit être associée à une fonction particulière sur D. 


Les calculs relationnels de tuples et de domaines se distinguent essentiel- 
lement par l'interprétation des variables : ce sont des tuples pour le cal- 
cul relationnel de tuples et des domaines pour le calcul relationnel de 
domaines. 


Etant donné une formule bien formée et une interprétation, nous 
pouvons assigner une valeur vrai ou faux à chaque formule atomique 
composant la formule bien formée : il suffit pour cela de faire corres- 
pondre au prédicat la valeur vraie si les éléments du domaine de discours 
satisfont la relation associée et faux sinon. Par application des tables de 
vérités (fig. V.18), il est possible d'assigner une valeur logique à la for- 
mule bien formée. 


Si une formule bien formée est vraie pour toute interprétation, on 
dit qu'elle est valide. Par exemple, la formule P(a) = P(a) V P(b) est 
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valide. Si une formule est vraie pour une interprétation donnée, on dit 
qu’elle est satisfaire pour cette interprétation. 











A B | 7B | A = B A VB AAB 
Vrai Vrai Faux Vrai Vrai Vrai 
Faux Vrai Faux Vrai Vrai Faux 
Vrai Faux Vrai Faux Vrai Faux 
Faux Faux Vrai Vrai Faux Faux 





Fig. V.18. — Tables de Vérité de 1, =, V, A 


4.3, — Quantificateurs et variables libres 


Fréquement, il arrive que l'on souhaite exprimer une assertion sur 
tous les éléments sur lesquels peut prendre valeur une variable X. Une 
telle assertion peut être exprimée à l'aide d'une conjonction de formules 
logiques correspondant à chacune des valeurs possibles de X, soient x,, x, 

.. X, ; on écrit alors : F(xj) À F(x) ... F(x,). 
Afin de simplifier l'écriture, on introduit le symbole « quel-que-soit » : 
(v) et l'on note la formule précédente par v X F(X). Le symbole v est 
appelé quantificateur universel ; la variable X est dite liée par le quanti- 
ficateur universel. 


De méme, on introduit le quantificateur existentiel « il existe » (3) ` 
pour noter la formule : F(xi) V F(xz) ... V F(xn) 


où X1, X2, ... Xn Sont les valeurs possibles d'une variable X ; cette formule 
est écrite 3 XF(X) ; la variable X est dite liée par le quantificateur 
existentiel. 


Toute variable non liée par un quantificateur dans une formule est 
dite variable libre. 


5. LE CALCUL RELATIONNEL DE TUPLES 


5.1. — Définition 


Le calcul relationnel de tuples [Codd 72] se déduit du calcul de pré- 
dicats en interprétant les formules bien formées comme suit : 
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a) Les variables sont associées à des tuples. 

b) Les seuls termes considérés sont les constantes associées aux valeurs 
des domaines des attributs (par exemple « ROUGE ») et les fonctions 
génératrices des attributs notés V.A où V est une variable et A un 
attribut (par exemple V. COULEUR). 

c) Les prédicats utilisés sont ceux permettant les comparaisons logiques, 
c’est-à-dire (2, +, <, x, >, =}, et la définition de la portée d'une 
variable sur une relation R du type R(V). 


L'élément essentiel est bien sûr l'association de tuples de relations aux 
variables. Nous introduisons sous forme de notion la définition du cal- 
cul relationnel de tuples. 


Notion 9 : Calcul relationnel de tuples (Tuple relational calculus) 

Langage d'interrogation de données formel permettant d'exprimer des questions 
à partir de formules bien formées dont les variables sont interprétées comme 
variant sur les tuples d'une relation. 


Il est possible de définir la syntaxe du calcul relationnel de tuples en 
forme normale de BACHUS (BNF) comme indiqué figure V.19. 


Question : = o[Projection/Formule] 
Formule : = Defvar | Defvar A Qualification 
Defvar Relation (Variable) | Defvar ^ Relation (Variable) 
Qualification :: = Terme © Terme | Terme © Constante 
| Qualification A Qualification | Qualification V Qualification 
| 3 Variable Qualification | v Variable Qualification 
| 7 Qualification 

















Terme x = Variable . Attribut 
Projection â Terme | Projection, Terme 
9 n «[»|2|s|z|s 
Variable x= A |B|C...|XjYIZ 


Fig. V.19. — BNF du calcul ralationnel de tuples. Les éléments soulignés 
(Relation, Attribut, Constante) sont des concepts de base du modèle relationnel 


A noter que toute variable apparaissant dans le critère de projection doit 
être libre dans la formule (non quantifiée). 
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5.2. — Exemples 


A titre d'illustration, nous allons appliquer le calcul relationnel de 
tuples à une base relationnelle décrivant des achats et des ventes de pro- 
duits stockés dans un magasin. Le schéma de la base est le suivant : 

PRODUIT (NPRO, NOMP, QTES, COULEUR) 

VENTE (NVEN, NOMC, NPRV, QTEV, DATE) 

ACHAT (NACH, DATE, NPRA, QTEA, NOMF) 


La relation PRODUIT se compose des attributs numéro de produit 
(NPRO), nom du produit (NOMP), quantité en stock (QTES) et couleur 
(COULEUR). La relation VENTE décrit les ventes de produits effec- 
tuées et se compose des attributs numéro de vente (NVEN), nom du 
client (NOMC), numéro du produit vendu (NPRV), quantité vendue 
(QTEV) et date de la vente (DATE). La relation ACHAT définit les 
achats effectués aux fournisseurs. Elle contient les attributs numéro 
d'achat (NACH), date d'achat (DATE), numéro du produit acheté 
(NPRA), quantité achetée (QTEA) et nom du fournisseur (NOMF). 


Les questions suivantes s'expriment comme indiqué. 


(Q1) Donner la liste des noms et des couleurs de tous les produits : 
{P.NOMP, P.COULEUR/PRODUIT (P)} 


(Q2) Donner les noms et les quantités en stock des produits de couleur 
rouge : 


(P.NOMP, P.QTES/PRODUIT (P) A (P.COULEUR = « Rouge »j] 


(Q3) Donner pour chaque produit en stock, le nom du fournisseur 
associé : 


(P.NOMP, A.NOMF/PRODUIT (P) A ACHAT (A) A (P.NPRO - A.NPRA)} 


(Q4) Donner, pour chaque produit en stock en quantité supérieure à 
100 et de couleur rouge, les couples nom de fournisseurs ayant 
vendu ce type de produit — nom de client ayant acheté ce type de 
produit avec le nom du produit : 


(P.NOMP, A.NOMF, V.NOMC/PRODUIT (P) A ACHAT (A) A VENTE (V) A 
(P.QTES > 100) A (P.COULEUR = « Rouge ») A (P.NPRO = V.NPRV) A 
(P.NPRO = A.NPRA)) 
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(Q5) Donner les noms des clients ayant acheté au moins un produit de 
couleur verte : 


{V.NOMC/2P VENTE (V) A PRODUIT (P) A (V.NPRV = P.NPRO) A 
(P.COULEUR = « Verte »)] 


(Q6) Donner les noms des clients ayant acheté tous les produits stoc- 
kés : 


(V. NOMC/vP VENTE (V) À PRODUIT (P) A (V.NPRV = P.NPRO)} 


(Q7) Donner les noms des produits fournis par tous les fournisseurs et 
achetés par au moins un client : 


(P.NOMPI/VB 3A 3V VENTE (V) A PRODUIT (P) A ACHAT (A) A ACHAT (B) 
A (P.NPRO = V.NPRV) A (P.NPRO = A.NPRA) A (A.NOMF = B.NOMF)| 


6. LE LANGAGE QUEL 


6.1. — Introduction 


Le langage QUEL [Zook 77] est le langage de manipulation de don- 
nées du système INGRES [Stonebraker 76], un des premiers systémes 
relationnels développé à l'Université de Californie Berkeley et commer- 
cialisé sur PDP.11 et VAX. Ce langage est aussi utilisé dans plusieurs 
machines bases de données, telle IDM. 


Le langage QUEL est dérivé du calcul relationnel de tuples auquel 
est ajoutée une syntaxe en anglais. De plus, les quantificateurs ne sont 
pas utilisés (v, 3). Une variable qui n'apparait pas dans le critère de 
projection, c'est-à-dire qui n'est pas directement utilisée pour composer 
le résultat d'une question, est implicitement quantifiée par a (quantifi- 
cateur existentiel). En remplacement et complément des fonctions de calcul 
(compte, moyenne, somme, minimum, maximum) sont introduites, Ainsi, 
une quantification par quel-que-soit (v) s'exprime par le fait que tous 
les tuples satisfont la formule de qualification. Finalement, QUEL per- 
met également les mises à jour de manière assez Sophistiquée. 
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6.2. — Déclaration des variables 


Afin d’exprimer des questions, QUEL sépare la définition des varia- 
bles de l'expression de la question. Une définition de variables s'effectue 
à l'aide de la clause : 


RANGE OF variable IS nom-de-relation 





La variable est associée avec la relation spécifiée. Plusieurs variables 
associées à plusieurs relations peuvent être déclarées par une clause 
RANGE. Les variables déclarées demeurent en principe connues jusqu'à 
une nouvelle déclaration ou la fin de session. 


A titre d'exemple, reprenons la base de données composée des rela- 
tions PRODUIT, VENTE et ACHAT introduite au paragraphe 5. La 
définition des variables nécessaires à l’expression des questions vues au 
paragraphe 5.2 peut être effectuée par les ordres suivants : 


RANGE OF P IS PRODUIT 
RANGE OF A, B, V IS ACHAT, ACHAT, VENTE 


6.3. — Recherches élémentaires 


Une recherche s'exprime à l'aide de la requéte : 


RETRIEVE [[INTO nom-de-relation] (liste résultat) 
[WHERE qualification] 


Une qualification est une formule bien formée du calcul relationnel 
de tuples sans quantificateur, mais pouvant inclure des fonctions, comme 
nous le verrons au paragraphe 6.4. Cette commande recherche tous les 
tuples qui satisfont la qualification, compose la liste résultat qui est, soit 
visualisée sur le terminal, soit rangée dans la nouvelle relation de nom 
nom-de-relation, ceci selon la présence de l'option [INTO nom-de-relation] 
ou non. La liste résultat est une suite d'attributs de variables ou de fonc- 
tions de ces attributs (voir 8 6.4). 


A titre d'illustration, nous exprimerons les questions Q1 à Q5 du 
paragraphe 5.2. 


(Q1) RETRIEVE P.NOMP, P.COULEUR 
(Q2) RETRIEVE P.NOMP, P.QTES 
WHERE (P.COULEUR - « Rouge ») 
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(Q3) RETRIEVE P.NOMP, A.NOMF 
WHERE (P.NPRO = A.NPRA) 

(Q4) RETRIEVE P.NOMP, A.NOMF, V.NOMC 
WHERE (P.QTES) > 100) A (P.COULEUR = « Rouge ») A 
(P.NPRO = V.NPRV) A (P.NPRO = A.NPRA) 

(Q5) RETRIEVE V.NOMC 
WHERE (V. NPRV = P.NPRO) ^ (P.COULEUR = « Verte ») 





6.4. — Recherche avec fonctions et Agrégats 


QUEL utilise les fonctions agrégation d'éléments somme (SUM), 
moyenne (AVG), compte (COUNT), minimum (MIN) et maximum 
(MAX). Il est possible de distinguer les agrégats simples et les agrégats 
par sous-ensembles. 


Un agrégat simple est effectué par une clause argument d'un 
retrieve ou deléte du type : 


fonction (Expression-d'attributs [WHERE qualification]) 


Un tel agrégat simple évalue une valeur scalaire unique. Plus précisé- 
ment, la fonction est calculée à partir des valeurs de l'expression d'attri- 
buts (en général un attribut, mais il est possible d'utiliser des expressions 
arithmétiques d'attributs) pour tous les tuples satisfaisant la qualifica- 
tion. Par exemple, à partir de la base de données vue au 5.2, la recherche 
de la moyenne des quantités en stock pour les produits rouges s'effec- 
tuera comme suit : 


RETRIEVE AVG (P.QTE WHERE P.COULEUR = « Rouge ») 


Les agrégats par sous-ensembles permettent d'appliquer les fonc- 
tions agrégats à des sous-ensembles (partitions) de tuples d'une relation. 
Afin de définir les sous-ensembles, un ou plusieurs attributs sont spéci- 
fiés, ou plus généralement un groupe d'expressions d'attributs. Chaque 
sous-ensemble correspond à une valeur du groupe d'expressions d’attri- 
buts. Le format général de la clause associée est : 


fonction (Expression-d'attributs 1 BY 
Expression-d'attributs 2 [,Expression-d'attributs 3... 
WHERE qualification) 


L'opérateur BY permet de grouper l'ensemble des tuples satisfaisant la 
qualification par valeur(s) des expressions d'attributs 2, 3... puis de cal- 
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culer la fonction pour les sous-ensembles de valeurs de l'expression 
d'attribut 1. Il est possible, par exemple, de retrouver les couleurs des 
produits et la somme des quantités en stock par couleur pour tous les 
produits vendus aprés le 10.02.82 et stockés en quantité supérieure à 100, 
à l'aide de la question : 


RETRIEVE P.COULEUR, SUM (P.QTES BY COULEUR WHERE 
(P.QTES > 100)) WHERE (P.NPRO = V.NPRV) À 
(V.DATE > « 10.02.82 ») 


6.5. — Quantification Universelle 


Le langage QUEL n'utilise pas de quantificateur. Une variable non 
utilisée pour construire le résultat d'une requéte est implicitement quanti- 
fiée par « il existe » (3). Pour exprimer des questions utilisant des varia- 
bles normalement quantifiées par « quel-que-soit » (v), on utilise la 
fonction COUNT en vérifiant que tous les tuples satisfont la qualifica- 
tion. A titre d'exemple, les questions Q6 et Q7 du paragraphe 5.2 
s'expriment comme suit : 


(Q6) RETRIEVE V.NOMC 
WHERE COUNT (P.NPRO WHERE (V.NPRV + P.NPRO)) = 
COUNT (P.NPRO) 

(Q7) RETRIEVE P.NOMP 
WHERE (P.NPRO = V.NPRV) A (P.NPRO = A.NPRA) A 
(COUNT (B. NOMF WHERE A.NOMF = B.NOMF) = 
COUNT (B.NOMF)) 


6.6. — Commandes de Modification 


Le langage QUEL comporte également une commande pour insérer 
des tuples dans la base : 


APPEND [TO] nom-de-relation (liste-d'attributs) 
[WHERE qualification] 


permet d'ajouter les tuples définis par la liste d'attributs à la relation 
nom-de-relation. La liste d'attributs est composée soit de doublets nom 
d'attribut = valeur, soit d'attributs extraits des tuples satisfaisant la 
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qualification (désignés par une variable suivie du nom de P'attribut en 
notation pointée). 

Par exemple, l'ajout d'une vente de 10 parapluies (on suppose ici 
qu'il existe un seul produit de nom parapluie) au client DUPONT pourra 
s'effectuer par la commande : 


APPEND TO VENTE 

(NVEN = MAX(NVEN) + 1, NOMC = « DUPONT », 
NPRV = P.NPRO, QTEV = 10, DATE = « 26.06.82 ») 
WHERE (P.NOMP = « Parapluie ») 


QUEL inclut évidemment des possibilités de mise à jour de tuples 
existants à l'aide de la commande : 


REPLACE variable (liste-d'attributs) WHERE qualification] 


qui permet de changer la valeur des.attributs figurant dans la liste pour 
tous les tuples de la variable satisfaisant la qualification. Par exemple, le 
retrait de 10 parapluies du stock s'effectuera par la commande : 


REPLACE P (QTES = QTES - 10) 
WHERE (P.NOMP = « Parapluie ») 


Finalement, il est aussi possible de supprimer des tuples d'une base 
de données par la commande trés simple : 


DELETE variable 
WHERE qualification 


Par exemple, la suppression de tous les produits de couleur rouge 
S'effectue par : 


DELETE P 
WHERE (P.COULEUR = « Rouge ») 


6.7. — Autres commandes 
QUEL comprend quelques commandes supplémentaires, en parti- 
culier : 


— pour créer une base de données : 
CREATDB nom-de-base 
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— pour créer une relation : 


CREATE nom-de-relation (nom d'attribut = format 
[, nom d'attribut = format]... 


— pour détruire une relation : 
DESTROY nom-de-relation 


— pour détruire une base : 

DESTROYDB nom-de-base 
et aussi pour déclarer des assertions que doivent vérifier les données 
(contraintes d'intégrité). QUEL est donc un langage de manipulation de 
données puissant et complet qui a le mérite d'étre opérationnel (plus ou 
moins en totalité) sur plusieurs systémes commercialisés. 


7. LE CALCUL RELATIONNEL DE DOMAINES 


7.1. — Définition 


Comme le calcul relationnel de tuples, le calcul relationnel de 
domaines [Pirotte 82] se déduit du calcul de prédicats. Cette fois, les 
variables sont associées aux domaines des attributs. Les autres interpré- 
tations des formules bien formées sont analogues à celles effectuées pour 
le calcul relationnel de tuples. Les prédicats utilisés sont ceux permettant 
les comparaisons logiques entre une variable et une constante, ou entre 
deux variables à l'aide des opérateurs (=, +, <, €, >, >} et la défini- 
tion de la portée de variables sur les domaines des attributs d’une rela- 
tion du type : R (A, : Xy, A; : X» … A, : Xa). Ainsi, le calcul relationnel 
de domaines peut étre introduit comme suit : 


Notion 10 : Calcul relationnel de domaines (Domain relational calculus) 
Langage d'interrogation de données formel permettant d'exprimer des questions 
à partir de formules bien formées dont chaque variable est interprétée comme 
variant sur le domaine d'un attribut d'une relation. 


La BNF du calcul relationnel de domaine est définie figure V.20. A 
noter qu’une simplification d’écriture permet de regrouper des prédicais 
de restriction du type (x, = C) et des prédicats de définition de variable 
du type R (A, : x, ... A; : X...) en écrivant : R (A, : X, ... A; : C ...). 


Les langages de manipulation de données relationnelles 123 





Question = {Projection/Formule} 

Formule = Defvar | Defvar A Qualification 

Defvar : = Relation (Domvar) | Defvar À Relation (Domvar) 
Domvar = Attribut: variable | Domvar, Attribut : Variable 


| Domvar, Attribut : Constante ] 
Qualification: = Variable © Variable | Variable © Constante 

| Qualification A Qualification | Qualification V Qualification 

| 3 Variable Qualification | v Variable Qualification 

| ? Qualification 





Projection | :: = Variable | Projection, Variable 
o x= «[»|2|e]z|s 
Variable =a |iblc...]|xI|lylz 


Fig. V.20. — BNF du calcul ralationnel de domaines. Les éléments soulignés 
(Relation, Attribut, Constante) sont définis au niveau du modèle de données relationnel 


A. noter que toute variable apparaissant dans le critére de projection 
(liste des variables résultats) V1, V2, ... V doit en général étre libre dans 
la formule F (non quantifiée). 


7.2. — Exemples 


Nous reprenons ici les exemples traités en 5.2 avec le calcul relation- 
nel de tuples, sur la base composée des relations PRODUIT, VENTE, 
ACHAT. Nous obtenons les questions suivantes : 


(Q1) (x, y / PRODUIT (NOMP : x, COULEUR : y] . 
(Q2) (x, z / PRODUIT (NOMP : x, QTES : z, COULEUR : « Rouge »)] 
(Q3) 1x, y / PRODUIT (NPRO : z, NOMP: xX} A 
ACHAT (NACH : z, NOMF : y)j 
(Q4) (x, y, z / PRODUIT (NPRO : t, NOM : x, QTES : u, 
COULEUR : « Rouge ») A ACHAT (NPRA : t, NOMF : y) 
A VENTE (NPRV : t, NOMC : z) A (u > 100)) 
(Q5) [x/3y VENTE (NOMC : x, NPRV : y) A PRODUIT (NPRO : y, 
COULEUR : « Verte »)] 
(Q6) [x/ vy VENTE (NOMC : x, NPRV : y)A PRODUIT (NPRO : yl 
(Q7) [x/ vy 3t VENTE (NOMC : z, NPRV : t) A PRODUIT (NPRO : t, 
NOMP : x) A ACHAT (NPRA : t, NOME : y) 
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A noter que la question (Q7) peut être simplifiée car la variable z est inu- 
tile puisque l'existence de t implique celle de z. On obtient alors : 


(Q7) _ tx / vy at VENTE (NPRV : t) A PRODUIT (NPRO : t, NOMP : x) 
A ACHAT (NPRA : t, NOMF : y)] 


8. LE LANGAGE QBE 


8.1. — Introduction 


Le langage Query-By-Exemple (QBE) [Zloff 77, IBM 78] est conçu 
pour être utilisé à partir d’un terminal. Il a été développé par M. ZLOFF 
à IBM Yorktown Heights et est commercialisé par IBM depuis 1980. Ce 
langage peut être considéré comme une mise en œuvre visuelle (basée sur 
des tableaux affichés) du calcul relationnel de domaine. 


L'idée de base du langage est de faire formuler une question à l’uti- 
lisateur par un exemple d’une réponse possible à la question. Pour cela, 
l'utilisateur provoque tout d'abord l'affichage du schéma des relations 
nécessaires à la question qu'il désire poser (sous forme de tableaux vides) 


PRODUIT |NPRO | NOMP | QTES | COULEUR 











| VENTE |nven [nomc | nery QTEV | DATE 


LE 


ACHAT NACH) DATE NPRA [orra NOMF 














Fig. V.21. — Schémas 
de Relations Affichés 
par QBE 
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par frappe du nom des relations correspondantes. Ainsi, des tableaux 
vides (avec seulement les en-têtes de colonne et nom de la relation asso- 
ciée) apparaissent sur l'écran. Par exemple, il est possible d'afficher le 
schéma des relations PRODUIT, VENTE et ACHAT (fig. V.21). 


8.2. — Expression d'une question élémentaire 


Comme indiqué ci-dessus, QBE peut être vu comme une implanta- 
tion à deux dimensions du calcul relationnel de domaines. Pour cela, les 
régles suivantes sont utilisées : 

1. Les attributs à projeter (résultats) sont définis en frappant P. (PRINT) dans 
la colonne associée. 

2. Les constantes sont tapées directement dans la colonne de l’attribut associé, 
précédées de l'opérateur de comparaison les reliant à l'attribut Si ce n'est pas 
= (c'est-à-dire <, €, >, >, 7 =). 

3. Les variables sont désignées par des valeurs exemples soulignées ; la valeur 
exemple soulignée est en fait le nom de la variable domaine et par suite QBE 
associera deux valeurs exemples soulignées identiques (c’est une même varia- 
ble). 

4. Le quantificateur « quel-que-soit » est appliqué à une variable en tapant ALL. 
devant son nom (l'exemple souligné) alors que toute variable non imprimée 
non précédée de P. est implicitement quantifiée par « il-existe ». 

5. Le connecteur V (OU) est exprimé en utilisant deux lignes (deux exemples) 
comme si l'on avait en fait deux questions, l'une avec la partie gauche et 
l'autre avec la partie droite de la qualification (aprés mise en forme normale 


disjonctive). 

A l’aide de ces règles simples, il est possible d'exprimer toute ques- 
tion du calcul relationnel de domaines. Nous avons, à titre d’illustration, 
formulé les questions introduites au paragraphe 5.2. Le lecteur pourra 
noter l'aspect naturel de ce langage par l'exemple qui peut étre simple- 
ment paraphrasé. 




















(QD PRODUIT | NPRO | NOMP | QTES | COULEUR 
P. P. 

(Q2 PRODUIT | NPRO | NOMP | QTES | COULEUR 
P. P. Rouge 














| 
| 
| 
i 
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(Q3) 


(Q4) 


(05) 


(Q6) 


(Q7) 


Bases de données 


























| PRODUIT NPRO NOMP | QTES COULEUR 
wo | P. | 
ACHAT | NACH DATE NPRA QTEA NOMF 
| 100 P. 






































PRODUIT | NPRO | NOMP | QTES | coULEUR 
100 | P. > 100 | Rouge 
VENTE | NVEN | NOMC| NPRV | QTEV | DATE 
P. 100 
ACHAT | NACH | DATE | NPRA | QTEA | NOMF 
100 P. 























PRODUIT 





COULEUR 


C 


OULEUR 























VENTE | NVEN NOMC NPRV QTEV DATE 
P. 10 

VENTE | NVEN NOMC NPRV QTEV DATE 
| 100 

















Les langages de manipulation de données relationnelles 127 





| PRODUIT | NPRO | NOMP | QTES | COULEUR 











[m] h] | 





| ACHAT | NACH | DATE | NPRA | QTEA | nome 
| 100 | | atre 











Notons que des conditions de recherche trop longues pour être formulées dans 
une colonne, peuvent être introduites dans une case condition en bas de l'écran. 


8.3. — Possibilités additionnelles d'interrogation 


QBE offre quelques possibilités supplémentaires par rapport au cal- 
cul relationnel de domaine. En particulier, il est possible d'enlever Péli- 
mination automatique des doubles lors des projections finales en spéci- 
fiant le mot clé ALL devant une variable résultat à imprimer. Par exem- 
ple, l'édition de tous les noms des clients à qui l’on a vendu des produits 
(sans élimination. des doubles) sera effectuée en réponse à la question repré- 
sentée figure V.22. 





VENTE | NVEN | NOMC | NPRV | QTEV | DATE | 











| P.ALL.CX | | | | 


Fig. V.22. — Non élimination des doubles en QBE 


Il est également possible d’obtenir des résultats triés par ordre crois- 
sant (mot clé AO.) ou décroissant (mot clé DO.). Par exemple, l'édition 
des noms de produits en stock en quantité supérieure à 100 par ordre 
alphabétique descendant sera obtenue par exécution de la question 
représentée fig. V.23. 





PRODUIT | NPRO NOMP QTES | COULEUR 

















P.DO.PX | > 100 | 


Fig. V.23. — Exemple de question avec résultats triés 


De plus, QBE offre des facilités pour accomplir les opérations de 
type fermeture transitive de relations. Le calcul de la fermeture transitive 


128 Bases de données 


est impossible avec les langages basés sur le calcul de prédicats. Soit par 
exemple, la relation représentée figure V.24. Tout composant peut aussi 
être un composé. 








NOMENCLATURE COMPOSÉ COMPOSANT 
VOITURE CHASSIS 
VOITURE CAISSE 
VOITURE MOTEUR 
MOTEUR PISTON 
MOTEUR ALLUMAGE 
MOTEUR CHEMISE 
PISTON BOULONS 
PISTON ECROUS 














Fig. V.24. — Relation Composé-Composant 


Si l'on veut par exemple rechercher les composants de voiture au 
deuxiéme niveau, il est possible d'utiliser la question représentée figure 
V.25. 















NOMENCLATURE | COMPOSÉ | COMPOSANT 






VOITURE 
cx 





Fig. V.25. — Recherche des composants de 2* niveau 


Ainsi, pour rechercher les composants de niveau n à partir d'un 
composant (ou les composés de niveau n à partir d'un composé), il faut 
une question à n lignes. Ceci peut étre fastidieux. Afin de simplifier, 
QBE autorise le mot clé L entre parenthéses précédé d'un nombre de 
niveaux (par exemple (2L)). Ainsi, la question précédente pourra aussi 
être formulée comme représentée figure V.26. 





NOMENCLATURE | COMPOSÉ | COMPOSANT | 











VOITURE | P.CY QL) 


Fig. V.26. — Autre manière de rechercher les composants de 2° niveau 
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La fermeture transitive du composé VOITURE consiste à rechercher les 
composants de tout niveau. Ceci est effectué en fixant un niveau varia- 
ble, comme représenté figure V.27. Une telle question n’est pas exprima- 
ble à l’aide du calcul relationnel de tuples ou de domaines. 





NOMENCLATURE COMPOSÉ COMPOSANT | 











VOITURE P.CY (6L) | 


Fig. V.27. — Fermeture transitive du composé VOITURE 


Il est aussi possible d’obtenir les composants de dernier niveau à l’aide 
du mot clé LAST. 


Finalement, QBE dispose également des fonctions agrégats : CNT 
(décompte), SUM (somme), AVG (moyenne), MAX (maximum) et MIN 
(minimum). Ces fonctions peuvent être appliquées à toute variable résul- 
tat à condition qu'elle soit précédée de ALL. Si l'on désire éliminer les 
doubles avant application de la fonction, il faut appliquer avant l'opéra- 
teur unique (mot clé UNQ). Par exemple, si l'on veut connaître la quan- 
tité en stock des produits de nom « VINS » on écrira la question repré- 


sentée figure V.28. 
PRODUIT | NPRO NOMP QTES COULEUR 
P.SUM.ALL.QV 


Fig. V.28. — Utilisation de la fonction SUM 








8.4. — Opérations de Mise à Jour 


QBE permet également la mise à jour de relations. Il est possible : 


— d'insérer des tuples dans une relation (opérateur I. en première 
colonne) ; la figure V.29 illustre l'insertion du produit de clé 200 ; 





| PRODUIT | NPRO | NOMP QTES | COULEUR 





I. | 200 | Balais 100 Bleu 


Fig. V.29. — Insertion du tuple de clé 200 
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— de modifier des attributs de tuples (opérateur U. en première 
colonne) ; la figure V.30 illustre la mise à jour des quantités en stock 
pour les produits de couleur rouge ; 











| PRODUIT | NPRO NOMP | QTES | COULEUR 
U. NX QX Rouge 
NX QX + 100 














Fig. V.30. — Mise à jour des quantités en stock des produits rouges 


— de supprimer les tuples dans une relation obéissant à un critère de 
sélection donné (opérateur D. en première colonne) ; la figure V.31 illus- 
tre la suppression des produits rouges de la relation produit. 











PRODUIT QTES COULEUR | 





Fig. V.31. — Suppression des produits rouges 


QBE permet enfin une définition trés dynamique de la base de don- 
nées. Comme avec QUEL et SQL, il est possible de créer et détruire des 
relations. De plus, il est permis d'étendre une relation en ajoutant des 
attributs. QBE est donc un langage trés souple et complet. Le produit 
IBM est compatible avec IMS en ce sens qu'il existe des utilitaires pour 
recopier une base IMS en base QBE. Cependant, le langage est totale- 
ment interprété et donc coûteux en temps d'exécution. 


9. UTILISATION DES LANGAGES DE MANIPULATION DE DONNÉES 
DEPUIS LES LANGAGES DE PROGRAMMATION 


9.1. — Type d'approches 


Plusieurs approches à l'utilisation des langages relationnels de mani- 
pulation de données depuis des langages de programmation ont été pro- 
posées. Elles peuvent être approximativement classées en deux types : 
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L'intégration d'un langage de manipulation de données dans un langage 
de programmation consiste à prendre un langage de manipulation exis- 
tant, construit indépendamment du langage de programmation, et à pro- 
poser des constructions permettant de l’utiliser à partir du langage hôte. 


L'extension d'un langage de programmation par un langage de manipu- 
lation de données consiste à prendre un langage de programmation exis- 
tant (en général PASCAL) et à proposer des extensions à l’aide de clau- 
ses plus ou moins spécifiques à la manipulation de données. La deuxième 
approche conduit à un ensemble en général plus cohérent, mais souvent 
non directement utilisable. 


Dans la suite, nous étudions un exemple caractéristique des deux 
types d'approche. 


9.2. — Intégration d'un langage de manipulation de données 
dans un langage de programmation 


Dans cette approche, le langage de programmation utilisé est un des 
langages de haut niveau actuellement disponible. Aucun de ceux-ci n'a 
été conçu, ni pour accéder, ni pour traiter des informations provenant 
d'une base de données. Il en résulte que le langage utilisé n'a aucune 
connaissance de la base, excepté par le biais des ordres intégrés (il serait 
plus juste de dire juxtaposés) en provenance des langages de manipula- 
tion. Ces derniers sont généralement distingués des ordres du langage par 
des signes spéciaux, par exemple $ en premier caractére dans SQL 
[Date 81], ** en début de ligne pour EQUEL qui résulte de l'intégration 
de SEQUEL dans le langage C [Allman 76]. 


Deux types de mise en ceuvre du langage sont possibles pour une 
telle intégration : pré-compilation des requétes bases de données ou 
interprétation à l'exécution. La deuxiéme approche, en général plus sim- 
ple, est plus coûteuse en temps. Comme nous le verrons ci-dessous, SQL 
permet simultanément ces deux approches. Du point de vue passage du 
mode procédural des langages de programmation au mode assertionnel 
des langages de manipulation, le probléme est résolu soit par l'introduc- 
tion de curseurs (SQL) ou de traitements dirigés par les données (traite- 
ments entre {} dans EQUEL). 


« Embedded SQL » [Date 81] est certainement l'approche la plus 
poussée d'intégration d'un langage de manipulation de données (en 
l'occurrence SQL de systéme R) dans un langage de programmation (en 
l'occurrence PL1). Dans cette approche, les attributs des relations mani- 
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pulées doivent être déclarés comme des variables spéciales PLI. Soit par 
exemple une base de données composée de la relation suivante : 


VINS (NV, CRU, DEGRÉ, QUANTITÉ) 


Un programme manipulant les attributs NV, CRU et QUANTITÉ devra 
les déclarer en PL1 dans un type compatible avec celui défini dans le 
schéma de la base, par exemple : 


1$ DCL VLU CHAR (5); 
2 $ DCL CRU CHAR (10) ; 
3 $ DCL QUANTITÉ FIXED BIN (15) , 


Le $ indique que ces attributs seront utilisés dans des ordres SQL ; ils 
peuvent aussi être utilisés en PL1 comme des attributs normaux. Après 
la déclaration des attributs, il est nécessaire de distinguer les ordres impli- 
quant la lecture d’un seul tuple et ceux conduisant à retrouver plusieurs 
tuples. Les premiers (SELECT d’un seul tuple, UPDATE, INSERT, 
DELETE) ne nécessitent pas l’utilisation de curseurs, et peuvent être insérés 
directement dans le programme. Par exemple, après lecture sur le termi- 
nal d’un numéro de VINS dans la variable VLU, il est possible d'exécu- 
ter l’ordre suivant : 


$ SELECT CRU, QUANTITÉ 
INTO $ CRU, $ QUANTITE 
FROM VINS 

WHERE NV = $ VLU; 


L'imbrication des ordres de sélection conduisant à des ensembles de 
tuples s'effectue à l'aide de curseurs. Un curseur est finalement, vu de 
l'extérieur, une sorte de fichier séquentiel défini par un ordre SQL qu'il 
est possible d'ouvrir (ordre $ OPEN) et de lire en séquentiel (ordre $ 
FETCH). Par exemple, la sélection et le traitement des crus et quantités 
des vins de degré supérieur à 14 pourront s'effectuer comme suit : 


$ LET C BE 
SELECT CRU, QUANTITÉ 
INTO $ CRU, $ QUANTITÉ 
FROM VIN 
WHERE DEGRÉ » 14: 
$ OPEN C: 
DO WHILE NOT « fin de fichier » 
$ FETCH C; 
.. «traitement »... 
END; 


$ CLOSE C 
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Un autre aspect essentiel du couplage langage de programmation - 
langage de manipulation est l'aspect opérationnel : il est souhaitable de 
pouvoir mettre au point des ordres en conversationnel au terminal 
(recherches ou mises à jour), puis de pouvoir les appeler depuis un pro- 
gramme. Ceci est difficile dans les langages qui utilisent la précompila- 
tion tel que SQL, car un ordre créé dynamiquement à la console ne peut 
étre compilé avec le programme qui l'utilise. Cette difficulté a été résolue 
par les concepteurs de SQL en introduisant deux commandes séparées 
explicites : 


— $ PREPARE < ordre objet > FROM < ordre source > ; 
— $ EXECUTE < ordre objet > ; 





qui permettent tout d’abord la compilation d’un ordre totalement ou 
partiellement saisi par le programme ($ PREPARE) puis son exécution 
après compilation ($ EXECUTE). 


En conclusion, cette approche qualifiée d’intégration peut être, 
comme dans le cas SQL, assez riche en possibilités. 


9,3. — Extension d'un langage de programmation 


Cette deuxiéme approche [Schmidt 77, Gardarin 82, Van de Riet 81] 
se différencie par le fait que l'on part d'un langage de programmation 
existant (souvent PASCAL) que l'on étend en général comme suit : 


1. par l'introduction d'un type de données « Relation » permettant de 
spécifier, à l'aide du langage de programmation, les attributs composant 
un tuple (type record en PASCAL) et en général l'attribut clé ; 

2. par la possibilité de définir des variables de type relation et de res- 
treindre le champ de variation de ces variables à l'aide de qualifications 
logiques ; 

3. par l'ajout au langage d'une clause « For each » permettant de 
balayer les tuples associés à une variable ; 

4. par l'ajout au langage de clauses de mise à jour de relations (inser- 
tion, suppression, modification de tuples). 


La mise en œuvre du langage s'effectue par compilation (éventuellement 
en plusieurs étapes). L'intégration de requêtes mises au point en conver- 
sationnel dans un programme n’est pas réellement prévue. 


Un exemple typique d'extension de langage de programmation est 
PASCAL/R [Schmitt 77]. Dans ce langage, il est possible de définir 
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comme des types PASCAL (record) les relations de la base, mais aussi 
des relations résultats de requêtes. Par exemple, la relation VINS serait 
définie comme suit : 


type TVINS = record ; 
NV : integer; 
CRU : texte; 
DEGRE : 10.18; 
QUANTITÉ : integer ; 
end; 
RVINS = relation VINS OF TVINS. 
var VINS : RVINS ; 





Ensuite, il est possible d’utiliser la variable VINS avec des constructions 
for each et if, par exemple pour construire une relation résultat de type 
VINS contenant les Beaujolais de degré supérieur ou égal à 12. 


La relation RESULTAT doit être déclarée comme suit : 


var RESULTAT : RVINS : 


Elle sera construite par le bloc d’instructions : 


begin 
RESULTAT : = []; 
for each vinrec in VINS do 
if (vinrec. cru = « Beaujolais ») and 
(vinrec. degré = 12) then 
RESULTAT : + [vinrec] ; 
end 


Il est également possible de la construire directement par un « construc- 
teur » de relations : 


RESULTAT : = [each (vinrec) in VINS: 
(vinrec. cru = « Beaujolais ») and (vinrec. degré = 12)]; 





En résumé, le langage offre à la fois des possibilités assertionnelles et des 
possibilités procédurales. 
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10. CONCLUSION 


Nous avons, dans ce chapitre, étudié les principaux langages de 
manipulation de données basés sur le modèle relationnel. De nouveaux 
langages sont bien sûr en cours de développement, En particulier, une 
école travaille aujourd’hui autour de la programmation fonctionnelle 
utilisée pour manipuler des bases de données [ACM 81]. Un effort 
important reste à faire afin de mieux intégrer les langages de program- 
mation et les langages de manipulation de données [Van de Riet 81], en 
particulier, en diversifiant les types de données de base traités par les 
SGBD relationnels (il faudrait, par exemple, ajouter des types textes, 
chaînes de. bits, vecteurs...), en réalisant une meilleure connexion des 
vues au langage, en accroissant les possibilités de mise au point conversa- 
tionnelle et de contróle de l'intégrité des données. 


11. RÉFÉRENCES 


[ACM 81]. — ACM Ed. N° 556810. « Proc. of Conference on Functional Pro- 
gramming Languages and Computer Architecture ». Octobre 1981, Port- 
smouth, U.S.A. 

[ALLMAN 76]. = ALLMAN E., HELD. « Embedding a Data Manipulation Lan- 
guage in a General Purpose Programming Language». Proc. 1976 ACM 
SIGPLAN/SIGMOD, Conf. on Data Abstraction, Mars 1976. 

[ARTAUD 74]. = ARTAUD A., NicoLas J.M. « An Experimental Query System : 
SYNTEX ». IFIPS 74, North-Holland Ed., pp 595-600, 1974. 


; [BERNSTEIN 81]. — BERNSTEIN P.A., GoopMan N. « The power of natural semi- 


joins ». SIAM Journal Comput. V10, N4, Novembre 1981. 

[Boyce 75]. — Boyce R.F. et al. « Specifying Queries as Relational Expres- 
sions : the SQUARE data Sub-Language ». Communications ACM V18, N11, 
pp 621-628. 

[CHAMBERLIN 76]. = CHAMBERLIN D.D. et al. « SEQUEL 2. A Unified 
Approach to Data Definition Manipulation and Control ». IBM Journal for 
Research, V20, N6, pp 560-575, 1976. 

[Copo 70]. — Copp E.F. « A Relationnel Model of Data for Large Shared 
Data Banks ». Communications ACM, V13, N6, Juin 1970, pp 377-387. 
[Copp 72]. — Copp E.F, « Further Normalization of the Database Relational 
Model ». Dans Database Systems, R. RUSTIN Ed., Prentice-Hall, 1971, pp 
377-387. 


136 Bases de données 


[Date 81]. — Date C.J. « An Introduction to Database systems ». Livre, The 
System Programming Series, Addison-Wesley, 1981, 3* édition. 

[GALLAIRE 79]. — GALLAIRE H., Minker J., NicoLas J.M. « Advances in Data 
Base Theory - Volume 1 ». Livre, Plenum Press, 1979, New York. 

[GarDARIN 82]. — GARDARIN G., MELKANOFF M. « Proving Consistency of 
Database Transactions Written in Extended Pascal ». IEEE Transactions on 
Software Engineering, Juillet 1982. 

[IBM 78]. = IBM Corporation. « Query Example Terminal Users Guide ». 
Manuel SH 20-2078-0, IBM 1978. 

[IBM 81]. — IBM Corporation. « SQL/Data System Concepts and 
Facilities ». Manuel GH 24-5013D, IBM 81. 

[NiLssoN 71]. — Nilsson J.N. « Problems-Solving Methods in Artificial Intelli- 
gence ». Livre, Computer Science Series, McGraw-Hill, 1971. 

[PiroTTE 78]. = PIROTTE A. « High Level Data Base Query Languages ». Dans 
Gallaire et Minker, Logic and Databases 1978, Plenum Press, New York. 
[Pirorre 82]. — PirotTE A., Louis G. « A Denotational Definition of the 
Semantics of DRC, a Domain Relational Calculus ». 8th Very Large Data 
Bases, Mexico, 1982. 

{[Scamior 77]. — SchMipr J.W. « Some High Level Language Constructs for 
Data of Type Relation ». ACM Transactions on Database Systems, V2, N3, 
Septembre 1977, pp 247-261. 

[Smith 75], = SMiTH J.M., Chana P.Y. « Optimizing the Performances ofa 
Relational Algebra Database Interface ». Communications ACM, V18, NIO, 
pp 569-579. 

[VAN de Riet 81]. = Van de Rigr P. et al. « High-Level Programming Features 
for Improving the Efficiency of a Relational Database System ». ACM Tran- 
sactions on Database Systems, V6, N3, Septembre 1981, pp 464-485. 

[ZLoFF 77]. — ZLorr M.M. « Query-by-Example : a Data Base Language ». 
IBM Systems Journal, V16, N4, pp 324-343. 

[Zook 77]. — Zook W. et al. « INGRES Reference Manual ». University of 
California, Berkley, 1977. 





VI. — LES MODÈLES D'ACCÈS 
ET LES LANGAGES 
NAVIGATIONNELS 


1. INTRODUCTION 


Les modèles étudiés dans ce chapitre permettent de représenter des 
objets complexes stockés dans des fichiers et des liens entre ces objets. Ils 
dérivent avant tout d’une approche système au pc blème des bases de 
données qui tend à privilégier l’optimisation des entrées-sorties. C’est 
pourquoi nous les appelons modèles d'accès. A ces modèles sont associés 
des langages de manipulation de données basés sur le parcours de gra- 
phes, appelés langages navigationnels. Ces langages sont aussi trés carac- 
téristiques des modèles d'accés. 


Nous présentons successivement les deux modéles d'accés les plus 
populaires, à savoir le modèle réseau et le modèle hiérarchique, avec un 
langage de manipulation caractéristique associé pour chacun. Le modéle 
réseau proposé initialement par le groupe DBTG du comité CODASYL 
est utilisé avec diverses variantes par de nombreux systèmes tels que : 
IDS.IX (CII Honeywell Bull), IDMS (Cullinane), EDMS (Xerox), 
DMS/1100 (Univac), DBMS/10 (Digital), PHOLAS (Philips) et aussi 
TOTAL (Cincom). Le modéle hiérarchique étendu est employé par les 
systémes trés répandus que sont IMS (IBM) et Systems 2000 (MRI-Intel). 
Finalement, nous concluons par une comparaison des différents modé- 
les. 


138 Base de données 


2. LE MODÈLE RÉSEAU 


2.1. — Introduction et notations 


Le modèle réseau a été proposé par le groupe DBTG du comité 
CODASYL [Codasyl 71]. Des rapports plus récents [Codasyl 78] ont 
apporté des améliorations ; une normalisation basée sur une nouvelle 
proposition du groupe est à l'étude. Le modéle réseau type CODASYL 
est aujourd'hui utilisé par plusieurs systémes [Cii 78, Cullinane 78, Uni- 
vac 79]. Notre présentation est basée sur l'implantation réalisée par CII- 
HB dans IDS.II (level 64). Le lecteur trouvera une présentation plus 
générale dans [Taylor 76]. 


La syntaxe de présentation des clauses utilisées est celle de 
CODASYL, à savoir : 


[a] signifie que a est optionnel, 


a signifie que l'une des options a ou b (ou exclusif) doit étre 
choisie, 


| al signifie que l’une des options a ou b, aucune ou plusieurs, 
b peuvent être spécifiées, 


[a]... signifie que la spécification a peut-être répétée entre 0 et n 
fois (n entier quelconque), 


{a} signifie que la spécification a doit être présente au moins 
une fois et peut être répétée. 


De plus, les mots clés obligatoires sont soulignés. 


2.2. — La définition des objets 


Les objets modélisés dans la base de données sont décrits à l’aide de 
trois concepts introduits comme les trois premières notions du chapitre : 
l'atome, l’agrégat et l'article. 


Notion 1 : Atome (Data Item) 
Plus petite unité de données possédant un nom. 


Les modèles d'accès 139 
Un atome est représenté par une valeur dans la base. 


Notion 2 : Agrégat (Data Agregate) 
Collection d'atomes rangés consécutivement dans la base et portant un nom. 


Il existe deux types d'agrégats : les vecteurs et les groupes répétitifs. Un 
vecteur est une suite d'atomes ayant les mémes caractéristiques, alors 
qu'un groupe répétitif est une collection de données qui apparait plu- 
sieurs fois consécutivement. Un groupe répétitif peut être composé 
d’atomes, de vecteurs ou même de groupes répétitifs. 


Collection d'agrégats et d'atomes rangés côte à côte dans la base de données constituant 


[cote 3 : Article (Record) 
l'unité d'échange entre la base de données et les applications. 


Un article peut à la limite ne contenir aucune donnée, 


Les articles sont définis au niveau du type dans le schéma au moyen 
d'une clause : 


RECORD NAME IS nom-d'article. 


Les atomes sont définis par un nom suivi d'un type. Les vecteurs sont 
des atomes pouvant apparaître plusieurs fois alors que les groupes répéti- 
tifs sont définis au moyen d'un arrangement hiérarchique des données 
dans l'article, spécifié par un niveau optionnel. Ainsi, la clause de défini- 
tion d'une donnée est : 


A "T . TYPE is spécification-de-type 
[niveau] nomde:donnee; | OCCURS entier-1 TIMES 








Une spécification de type précise le domaine de la donnée (décimal, 
binaire, caractères). Avec IDS/II, level 64, les possibilités sont définies 


par : 


SIGNED PACKEDY DECIMAL entier 2, [entier 3] 
UNPACKED 


SIGNED BINARY 174 


CHARACTER entier 4 
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A titre d'exemple, nous décrivons (fig. VI.1) un type d'article VINS 
regroupant les cinq derniers millésimes (Années et Degré) d'un cru défini 
par un numéro (NV) et un nom de cru (CRU). 

RECORD NAME IS VINS. 

02 NV TYPE IS SIGNED PACKED DECIMAL 5. 

O2 CRU TYPE IS CHARACTER 10. 

02 MILLESIME OCCURS 5 TIMES. 

03 ANNEE TYPE IS SIGNED UNPACKED DECIMAL 4. 
03 DEGRE TYPE IS BINARY 15. 


Fig. VI.1. — Une description d'article 


2.3. — La définition des associations 


En CODASYL, il est seulement possible de définir des associations 
entre un article appelé propriétaire et n articles membres. Ces associa- 
tions, qui sont donc à un niveau purement hiérarchique mais qui, utili- 
sées à plusieurs niveaux, peuvent permettre de former aussi bien des 
arbres, des cycles que des réseaux, sont appelées ensemble (en anglais 
set). 


Notion 4 : Ensemble (Set) 
Association entre un article propriétaire et n articles membres. 


Cette définition est à appliquer au niveau des types aussi bien qu'au 
niveau des occurrences : un type d'ensemble permet d'associer un type 
d'article propriétaire à un ou plusieurs types d'articles membres ; une 
occurrence d'ensemble permet d'associer une occurrence d'article pro- 
priétaire à n occurrence d'articles membres. Deux limitations sont 
importantes : un type d'article ne peut étre à la fois propriétaire et mem- 
bre d'un méme ensemble, une occurrence d'article ne peut appartenir à 
plusieurs occurrences du méme ensemble. 


Les éléments ci-dessus permettent de définir la notion de base de 
données réseau. 


Notion 5 : Base de Données Réseau (Network database) 
Base de données composée d'articles reliés entre eux par des ensembles. 


La définition s'applique aussi bien au niveau des types (les types d'arti- 
cles sont reliés par des types d'ensembles) qu'au niveau des occurrences 
(les occurrences d'articles sont reliées par des occurrences d'ensembles). 
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Une base de données réseau se représente au niveau des types à 
l'aide d'un graphe des types dont les sommets sont les noms des types 
d'articles et dont les arcs représentent les types d'ensembles [Bachman 
69]. Les arcs sont orientés du type propriétaire vers le type membre. Cha- 
que arc est valué par le nom du type d'ensemble qu'il représente et cha- 
que sommet par le nom du type d'article associé. 


A titre d'exemple, nous allons présenter le graphe des types d'une 
base de données vinicole composée des articles : 
— VINS décrits ci-dessus, 
— BUVEURS composés des atomes numéro de buveur, nom et prénom, 
— ABUS décrivant pour chaque vin, la quantité bue par un buveur, 
— PRODUCTEURS définissant pour chaque vin, le nom-et la région 
du producteur, 
— COMMANDES spécifiant les commandes de vins passées par les 
buveurs aux producteurs. 


Les ensembles considérés sont : 

— RÉCOLTE qui associe un producteur aux vins récoltés, 

— VENTE qui associe un vin aux commandes correspondantes, 

— ACHAT qui associe un buveur à ses commandes, 

— DÉGUSTATION qui associe un buveur à une quantité de vins bue, 

— CONSOMMATION qui associe un vin à toutes ses quantités bues 
par les différents buveurs. 


Le graphe des types de cette base est représenté figure VI.2. 


CONSOMMATION, 






DÉGUSTATION 










ACHAT 


COMMANDES 


VENTE 
RÉCOLTE 


PRODUCTEURS 






Fig. VI.2. — Exemple de Graphe des types d'une base de données réseau 


Afin de mieux faire comprendre la notion d'ensemble, il est aussi 
possible de représenter une base de données réseau par un graphe au 
niveau des occurrences. Dans ce cas, les articles d'une occurrence 
d'ensemble sont reliés par un cycle. Par exemple, figure VI.3 nous avons 
représenté des occurrences des articles VINS, ABUS et BUVEURS par 
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des cercles, et des occurrences des ensembles CONSOMMATION et 
DEGUSTATION par des cycles d'occurrences d'articles. 





VINS 

— Consommation 
ABUS 

— Dégustation 
BUVEURS | 


Fig. VI.3. —- Exemple de graphe d'occurrences d'une base de données réseau 


En CODASYL, la clause de définition d'un ensemble, qui se situe 
bien évidemment au niveau des types, est structurée comme suit : 


SET NAME is nom-d'ensemble 
OWNER is nom-d'article 
MEMBER is nom-d'article...]... 


Nous verrons ci-dessous les détails des sous-clauses OWNER et MEM- 
BER. Plusieurs types de membres peuvent être spécifiés par répétition de 
la clause MEMBER. 


CODASYL autorise la définition d'ensembles singuliers avec une 
seule occurrence. Pour cela, il suffit d'utiliser la définition de proprié- 
taire : 


OWNER IS SYSTEM 


Tous les articles membres sont alors chaînés entre eux dans une seule 
Occurrence. Ceci permet de rechercher un article parmi les membres 
comme dans une occurrence d'ensemble normale et aussi de chaîner des 
articles singuliers. 
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2.4. — L'ordonnancement des articles dans les ensembles 


Les articles dans les occurrences d'ensemble sont ordonnés. Lors de 
l'insertion d’un article dont le type est membre d'un ensemble, il faut 
tout d'abord choisir l'occurrence d'ensemble dans laquelle l'article doit 
étre placé. Nous étudions ci-dessous les méthodes possibles pour ce 
choix. Ensuite, l'article doit être inséré dans la suite des articles compo- 
sant les membres de l'occurrence d'ensemble. Les choix possibles de la 
position de l'article sont les suivants : 


— en début (FIRST) ou fin (LAST) de la suite des membres, 

— juste avant (PRIOR) ou juste aprés (NEXT) le dernier article de la 
suite des membres accédé par le programme effectuant l'insertion, 

— par ordre de tri (SORTED) croissant ou décroissant d'une donnée 
des articles membres ; dans ce cas, la donnée doit être définie comme 
une clé (KEY) dans la clause membre ; les cas de doubles doivent être 
prévus ; également, si l'ensemble comporte plusieurs types d'articles, 
l'ordre des types doit &tre précisé. 


La figure VI.4 représente ces diverses possibilités pour l'insertion 
dans une occurrence de l'ensemble CONSOMMATION. 


Ces possibilités doivent étre définies au niveau du schéma à l'aide de la 
clause : 


ORDER IS PERMANENT INSERTION IS 








FIRST 
LAST 
PRIOR 
NEXT 
WITHIN RECORD-TYPE 
BY DEFINED KEYS 
SORTED [RECORD-TYPE SEQUENCE is (nom-d'article;]...] 








FIRST 
[DUPLICATES ARE 4 LAST 
NOT ALLOWED 


Cette clause est placée dans la définition de l'ensemble (clause SET) juste 
aprés la définition du propriétaire (sous-clause OWNER). 
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FIRST LAST 


PRIOR SORTED 





Dernier Q3) Article à insérer 


article de l'ensemble 
accédé par le programme 


Fig. VI.4. — Possibilités d'insertion dans un ensemble 


Pour chacun des membres, dans le cas où l'option SORTED est 
retenue, il faut préciser la clé de tri. Ceci est fait au moyen de la clause 
optionnelle : 


KEY i ASCENDING nom-de-données À 
SEY IS DESCENDING RECORD-TYPE 5s 





FIRST 
DUPLICATES ARE | LAST | 
NOT ALLOWED 


L'option RECORD-TYPE précise que seuls les types d'articles sont pris 
en compte pour le tri ; la séquence est alors précisée au niveau de la 
clause ORDER. 


2.5. = La sélection d'occurrence d'un type d'ensemble 


Il existe autant d'occurrences d'ensemble que d'articles propriétai- 
res. Lors d'une insertion ou d'une recherche, il y a donc nécessité de 
sélectionner l'occurrence choisie. Ceci est effectué par parcours d'un 
chemin dans le graphe des occurrences d'ensembles depuis un article 
point d'entrée, jusqu'à l'article propriétaire de l'occurrence d'ensemble 
cherchée. Le mode de sélection du chemin est précisé par la clause SET 
SELECTION définie pour chaque ensemble comme suit : 
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SET SELECTION [FOR NOM-d'ensemble-1] is 
THRU nom-d'ensemble - 2 OWNER IDENTIFIED BY 
APPLICATION 
foxrecnsener [EQUAL TO nom-de-paramètre 1] 


CALC KEY [EQUAL TO nom-de-paramétre 2] 





p THRU nom-d'ensemble 3 WHERE OWNER IDENTIFIED BY 





(nom-de-donnée 3 [EQUAL TO nom-de-paramètre 3J}... 


La première partie de la clause (THRU) permet de spécifier le mode 
de sélection du point d'entrée. Deux approches sont possibles : 
— par application, ce qui signifie que l'article propriétaire a pu être, 
préalablement à la recherche ou à l'insertion, repéré par le programme 
d'application, comme nous le verrons au niveau du langage de manipula- 
tion ; 
— par clé (DATA-BASE-KEY ou CALC KEY) fournie par le pro- 
gramme en paramétre ; le premier type de clé est en quelque sorte une 
adresse relative d'article et le deuxiéme une donnée servant au placement 
par hachage des articles comme nous le verrons ci-dessous. 


La deuxième partie (THEN THRU) est optionnelle dans le cas où 
l'on désire parcourir un-chemin de longueur supérieur à un ensemble 
dans le graphe des.occurrences. Elle permet, de manière récursive 
lorsqu'elle est répétée, de sélectionner une occurrence d'ensemble par 
recherche du propriétaire dans les membres de l'occurrence précédem- 
ment sélectionnée. Cette recherche s'effectue par balayage de l’occur- 
rence de l’ensemble de niveau supérieur jusqu’au premier article ayant 
pour valeur de la donnée nom-de-donnée 3 la valeur contenue dans nom- 
de-paramétre 3 ; cette donnée (nom-de-donnée 3) doit d’ailleurs en prin- 
cipe être discriminante dans l’occurrence d’ensemble [pas de doubles 
autorisés]. 


2.6. — Les options d'insertion dans un ensemble 


Lors de l’insertion d’un article dans la base, celui-ci peut, pour cha- 
cun des ensembles dont son type d’article est déclaré membre : 


— être inséré automatiquement dans la bonne occurrence de l'ensemble 
sélectionnée par le systéme en accord avec la SET SELECTION (option 
INSERTION IS AUTOMATIO) ; 

— ne pas être inséré automatiquement par le système ; dans ce cas, le 
programme devra, s'il le désire, faire l'insertion par une manipulation 
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spéciale (option INSERTION IS MANUAL) que nous étudions au 
niveau du langage de manipulation. 


De plus, une contrainte d’intégrité spécifique peut être précisée : 
l'association entre deux types d'articles reliés par un ensemble est décla- 
rée « obligatoire » (option MANDATORY) ou « facultative » (option 
OPTIONAL). Dans le premier cas, tout article du type des membres 
d'un ensemble sera forcément membre d'une occurrence de cet ensem- 
ble, alors qu'il ne le sera pas forcément dans le deuxiéme cas. 


Ces options d'insertion sont précisées pour chaque type de membre 
par la clause : 


AUTOMATIC 


INSERTION IS | MANUAL 


| RETENTION IS fuan paron] 


OPTIONAL 


2.7. — Le placement des articles 


Une base de données CODASYL est placée dans un ensemble de 
fichiers appelés AREA. Ces fichiers sont soit des fichiers relatifs (adres- 
sage par numéro de page et d’octet dans la page), soit des fichiers aléatoi- 
res (adresse relative calculée par une fonction de hachage). 


Chaque article est repéré dans la base par une clé base de données 
(data base key) qui lui est affectée à sa création et permet de l'identifier 
jusqu’à sa disparition. 


Notion 6 : Clé Base de Données (Database-key) 
Repére associé à un article lors de sa création invariant et permettant de le retrouver sans 
ambiguïté. 


Bien que CODASYL n'est pas spécifié le format des clés base de don- 
nées, la plupart des systèmes réseaux attribuent une place fixe aux arti- 
cles, si bien qu'une clé base de données peut être un numéro de fichier, 
suivi d'un numéro de page et d'un déplacement dans la page permettant 
de retrouver l'en-tête de l'article. 


Le placement d'un article consiste à calculer son adresse dans la 
base, ainsi que sa clé base de données qui en découle en général directe- 
ment. 


Notion 7 : Placement CODASYL (CODASYL location mode) 
Méthode de calcul de l'adresse d'un article et d'attribution de la clé base de données lors 
de la première insertion. 
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Le mode de placement est défini dans le schéma pour chaque type d’arti- 
cle selon plusieurs procédés possibles. 


Tout d’abord, la clé base de données peut être fourni directement 
par l’utilisateur comme un paramètre du programme. Ce mode, appelé 
mode direct (mot clé DIRECT) est en général réservé aux programmeurs 


systèmes. 


Le mode le plus simple est l’aléatoire classique : une clé, par forcé- 
ment discriminante, est précisée et le système calcule l'adresse de l’article 
à l’aide d'une procédure de hachage. Ce mode, appelé mode calculé est 
spécifié par les mots clés CALC USING. i 


Un mode plus complexe, mais permettant en général de bonnes 
optimisations, est le mode par ensemble, spécifié par le mot clé VIA. Ce 
mode possède deux variantes selon que l’article est placé dans le même 
fichier que son propriétaire dans l’ensemble considéré, ou dans un 
fichier différent. Dans le premier cas, l’article est placé à proximité du 
propriétaire (dans la même page ou des pages voisines), alors que dans le 
second il est placé dans un autre fichier que celui du propriétaire par 
homothétie. Plus précisément, le placement par homothétie consiste à 
calculer l’adresse de la page dans laquelle on place l’article (AA) à partir 
de l’adresse page du propriétaire (AP) comme suit : 


AA = AP " TAITP 


où TA désigne la taille du fichier contenant l'article et TP la taille du 
fichier contenant le propriétaire. L'avantage de cette méthode est, qu'en 
général, tous les articles ayant méme propriétaire dans l'ensemble consi- 
déré sont placés dans la m&me page (ou des pages voisines). Ainsi la 
méthode par homothétie réduit le temps de parcours des membres d'une 
occurrence d'ensemble, alors que la méthode par proximité réduit le 
temps de parcours des occurrences d'ensemble mais en général accroît 
celui du fichier. 


Les diverses possibilités de placement sont définies par la clause : 


DIRECT nom-de-paramétre 
CALC USING nom-de-donnée 
LOCATION MODE IS —— 
eR DUPLICATES ARE [NOT] ALLOWED 
VIA nom-d'ensemble SET 








PENES 
(fx AREA } 
WITHIN (nom-d'area]... [AREA-ID is nom-de-paramètre] 
AREA OF OWNER 





148 Base de données 


2.8. — Exemple de schéma 


A titre d'exemple, nous donnons figure VI.5 un schéma possible 
pour la base de données dont le graphe des types a été présenté figure 
VI.2. La base a été placée dans trois fichiers (F-BUVEURS, F- 
PRODUCTEURS et F-COMMANDES). Les articles ABUS et VINS 
sont placés à proximité des propriétaires, respectivement BUVEURS et 
PRODUCTEURS eux-mêmes placés par hachage. L'article COMMAN- 
DES est placé dans le fichier F-COMMANDES par homothétie avec le 
fichier F-BUVEURS. 


SCHEMA NAME IS VINICOLE ; 
AREA NAME IS F-BUVEURS ; 
AREA NAME IS F-PRODUCTEURS ; 
AREA NAME IS F-COMMANDES ; 


RECORD NAME IS BUVEURS ; 
LOCATION MODE IS CALC USING NB DUPLICATES 
NOT ALLOWED WITHIN F-BUVEURS ; 
02 NB TYPE IS SIGNED PACKED DECIMAL 5; 
02 NOM TYPE IS CHARACTER 10; 
02 PRENOM TYPE IS CHARACTER 10; 


RECORD NAME IS ABUS ; 
LOCATION MODE IS VIA DEGUSTATION 
WITHIN. AREA OF OWNER ; 
02 QUANTITE TYPE IS SIGNED BINARY 15; 


RECORD NAME IS PRODUCTEURS ; 
LOCATION MODE IS CALC USING NOM DUPLICATES 
ALLOWED WITHIN F-PRODUCTEURS ; 
02 NOM TYPE IS CHARACTER 10; 
02 REGION TYPE IS CHARACTER 8; 


RECORD NAME IS VINS ; 
LOCATION MODE IS VIA RECOLTE WITHIN AREA OF OWNER ; 
02 NV TYPE IS SIGNED PACKED DECIMAL 5; 
02 CRU TYPE IS CHARACTER 10; 
02 MILLESIME OCCURS 5 TIMES ; 
03 ANNEE TYPE IS SIGNED UNPACKED DECIMAL 4; 
03 DEGRE TYPE IS SIGNED BINARY 15; 








RECORD NAME IS COMMANDES ; 
LOCATION MODE IS VIA ACHAT WITHIN F-COMMANDES ; 
02 DATE TYPE IS CHARACTER 8; 
02 QUANTITE TYPE IS SIGNED BINARY 15; 


Les modèles d'accès 149 


SET NAME IS DEGUSTATION ; = 0000. "a 
OWNER IS BUVEURS ; 3 
ORDER IS PERMANENT INSERTION IS LAST;— ^ 
MEMBER IS ABUS ; 

INSERTION IS AUTOMATIC RETENTION ÍS MANDATORY ; 

-FSET SELECTION.EOR DEGUSTATION Jis 

(THRU DEGUSTATION OWNER IDENTIFIED BY ÇAI 


SET NAME IS CONSOMMATION ; 
OWNER IS VINS; 
ORDER IS PERMANENT INSERTION IS NEXT ; 
MEMBER IS ABUS ; 





C KEY; 









_INSERTION IS AUTOMAT JS MANDATORY ; 
SET SELECTION(FOR CONSOMMATION/IS Sdrselaoheo te H 
THRU CONSOMMATION OWNER IDENTIFIED  fhru Recothe owner 
BY APPLICATIONS ; Tel dard fred lyy coda. Bees. 
— t K 





SET NAME IS RECOLTE; 
OWNER IS PRODUCTEURS ; 
ORDER IS PERMANENT INSERTION IS SORTED 
BY DEFINED KEYS DUPLICATES ARE FIRST ; 
MEMBER IS VINS; 
INSERTION IS MANUAL RETENTION IS OPTIONAL ; 
_ KEY IS ASCENDING CRU ; 

ÉT SELECTION IS 


SET N NAME IS VENTE ; 
OWNER IS VINS ; 
ORDER IS PERMANENT INSERTION IS SORTED 
BY DEFINED KEYS DUPLICATES ARE NOT ALLOWED ; 
MEMBER IS COMMANDES ; 
INSERTION IS AUTOMATIC RETENTION IS MANDATORY ; 
IS DESCENDING DATE DUPLICATES NOT ALLOWED ; 
SET SELECTION IS 
THRU RECOLTE OWNER IDENTIFIED BY CALC KEY 






SET NAME IS ACHAT; 
OWNER IS BUVEURS ; 
ORDER IS PERMANENT INSERTION IS LAST ; 
MEMBER IS COMMANDES ; 
INSERTION IS AUTOMATIC RETENTION IS MANDATORY ; 
SET SELECTION IS 
THRU ACHAT OWNER IDENTIFIED BY APPLICATION ; 


END-SCHEMA. 
Fig. VI.5. — Exemple de schéma CODASYL 
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Des choix sont faits pour les ordres d’insertion, les contraintes de réten- 
tion et les modes de sélection des ensembles. Ces choix devront être res- 
pectés lors de l'écriture des programmes de manipulation. 


3. LE LANGAGE DE MANIPULATION COBOL-CODASYL 


3.1. — Sous-schéma COBOL ^ 


Un schéma externe en CODASYL est appelé sous-schéma ; en fait, 
la notion de sous-schéma est en général plus restrictive que celle de 
schéma externe, car il s'agit d'un sous-ensemble proprement dit du 
schéma, en ce sens que l'on ne peut qu'omettre des types d'articles, des 
fichiers (area), des ensembles et des données. 


Notion 8 : Sous-schéma (Sub-schema) 
Sous-ensemble du schéma vu par un programme d'application. 


Outre la possibilité de ne définir qu'une partie des données, des articles, 
des ensembles et des fichiers, d'autres variations importantes peuvent 
exister entre le schéma et un sous-schéma, en particulier : 


— J'ordre des atomes dans un article peut être changé, 

— les caractéristiques (types) d’un atome peuvent être changées, 
— les clauses SET SELECTION peuvent être redéfinies, 

— tous les noms peuvent être changés. 


Un sous-schéma COBOL se compose en principe de trois divisions : 
une division titre (title division) qui nomme le sous-schéma et le relie au 
schéma, une division de transformation (mapping division) qui permet 
de définir les synonymes et une division des structures (structure divi- 
sion) où sont définis les fichiers (appelés REALM en COBOL car le mot 
clé AREA est utilisé à d'autres fins), les articles et les sets. A titre 
d'exemple, nous donnons figure VI.6, un sous-schéma de la base vini- 
cole que pourrait définir un administrateur pour des programmes s'inté- 
ressant seulement aux articles buveurs, commandes et abus (à l'exception 
du numéro de buveur). 
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TITLE DIVISION 
SS CLIENT WITHIN SCHEMA VINICOLE 
MAPPING DIVISION 
ALIAS SECTION 
AD SET BOIT IS DEGUSTATION 
AD SET ACHETE IS ACHAT 
STRUCTURE DIVISION 
REALM SECTION 
RD F-BUVEURS 
RD F-COMMANDES 
RECORD SECTION 
01 BUVEURS 
02 NB PICTURE IS 999 
02 NOM PICTURE IS X(10) 
02 PRENOM PICTURE IS X(10) 
01 ABUS 
02 QUANTITE PICTURE IS 999 
01 COMMANDES 
02 QUANTITE PICTURE IS 999 
02 DATE PICTURE IS X(8) 
SET SECTION 
SD BOIT 
SD ACHETE 


Fig. VI.6. — Sous-schéma COBOL 


3.2. — La navigation CODASYL 


Une fois qu'un schéma et des sous-schémas ont été définis, des pro- 
grammes d'applications peuvent être écrits. Ceux-ci invoquent le système 
de bases de données à l'aide des verbes du langage de manipulation qui 
sont inclus dans un programme COBOL. Les verbes peuvent étre classés 
en quatre types : 

— la recherche d'articles (FIND) 
— les échanges d'articles (GET, STORE) 
— la mise à jour (ERASE, CONNECT, DISCONNECT, MODIFY) 


„= le contrôle (READY, FINISH). 


Les échanges d'articles s'effectuent par une zone de travail tampon 
appelée « USER WORKING AREA » dans laquelle les articles fournis 
par le SGBD sont chargés (GET), et ceux fournis par le programme sont 
placés avant d'étre rangés dans la base (STORE). Chaque atome ou arti- 
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cle décrit dans le sous-schéma a une place assignée dans la zone de travail 
^. sor $i ———MÓÀd4—MM M r1 
et peut être référencé par son nom dans le sous-schéma. 


La recherche d'articles ne provoque pas d'échange de données entre 
le programme et le SGBD. Seul des pointeurs associés au programme et à 
des collections d'articles, appelés curseurs, sont déplacés par les ordres 
de recherche (FIND). 


Notion 9 : Curseur (Currency) 


Il existe plusieurs curseurs associés à un programme en exécution : 


— un curseur indique-l'article courant.du programme, c'est-à-dire en 
principe le dernier article lu, écrit ou simplement cherché par le pro- 
gramme ; 

— un curseur indique l'article courant de chaque type d'article réfé- 
rencé ; 

— un curseur indique l'article courant de chaque type d'ensemble réfé- 
rencé ; 

— un curseur indique enfin l'article courant de chaque type de fichier 
(realm) référencé. 


Le nombre de curseurs associés à un programme est donc (1 -- Nombre 
de types d'articles + Nombre de types d'ensembles + Nombres de 
fichiers) figurant dans le sous-schéma. Les curseurs sont déplacés gráce 
aux divers types de FIND que nous allons étudier. L'article pointé par le 
curseur du programme et seulement celui-ci peut étre obtenu par celui-là 
en zone de travail. Ainsi, un programme se déplace dans la base en 
déplacant son curseur : on dit qu'il navigue [Bachman 73]. 


3.3. — La recherche d'articles 


La recherche d'articles consiste donc à déplacer les curseurs dans la 
base. Elle s'effectue à l'aide de l'instruction FIND. L'exécution d'une 
telle instruction déplace toujours le curseur du programme, mais il est 
possible d'empécher sélectivement le déplacement des autres curseurs. 
S'il n'a pas été spécifié qu'un curseur ne doit être déplacé, il est reposi- 
tionné dés qu'un article de la collection à laquelle il est associé (type 
d'articles, ensembles, fichiers) est accédé (lu, écrit ou recherché). 


| 
| 
i 
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Le format général de l'instruction de recherche est : 
FIND expression-de-sélection [ RETAINING CURRENCY FOR 


MULTIPLE 


| RECORD 
{ SETS } | 





(nom d'ensemble}... 


L'expression de sélection spécifie le critère de recherche. La rétention du 
déplacement de tous les curseurs — à l’exception de celui du programme 
— s'effectue par l'option : 


RETAINING CURRENCY FOR MULTIPLE 


Les autres choix de rétention de curseurs peuvent étre combinés. Ci- 
dessous, nous examinons les divers types de FIND résultant des diverses 
expressions de sélections possibles. 


3.3.1. — La recherche sur clé 


Comme indiqué au paragraphe 2, un article posséde toujours une 
clé base de données (DATA BASE-KEY) et peut posséder une clé de 
hachage — avec ou sans double — s'il a été placé en mode calculé. On 
obtient ainsi trois possibilités de recherche sur clé : 


— Recherche connaissant la clé base de données : 
FIND nom-d'article DB-KEY IS nom-de-paramétre. 


(C Recherche connaissant-la-clé calculée unique z> 








FIND ANY nom-d'article. 


— Recherche connaissant la clé calculée avec doubles : 
FIND DUPLICATE nom-d'article. ` 


Dans le cas de recherche sur clé calculée, la valeur de celle-ci doit préla- 
blement être chargée par le programme en zone de travail. 


3.3.2. — La recherche dans un fichier 


Il est possible de sélectionner le premier, le dernier, l'article suivant 
ou précédent l'article courant, ainsi que le i* article d'un fichier. Le for- 





i 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
i 
| 
| 
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mat de l'instruction de recherche en fichier est : 


FIND PRIOR nom-d'article WITHIN nom-de-fichier 





paramètre 


3.3.3. — La recherche dans un ensemble 


De méme que dans un fichier, il est possible de sélectionner le pre- 
mier, le dernier, l'article suivant ou précédent l'article courant ainsi que 
le premier article de l'occurrence courante d'un ensemble. Le format de 
l'instruction est identique à celui de la recherche en fichier : 


FIRST 


FIND PRIOR nom-d'article WITHIN nom-d'ensemble 


Il est également possible de rechercher un article à partir d'une 
valeur de donnée dans l'occurrence courante d'un ensemble. Selon que 
l’on recherche la première (ou l'unique) occurrence d'article ou la sui- 
vante, on emploie : 


FIND nom-d'articie WITHIN nom-d'ensemble USING (nom-de-donnée]... 
FIND DUPLICATE WITHIN nom-d'ensemble USING (nom-de-donnéej.. 


La donnée dont la valeur est utilisée pour ce type de recherche associa- 
tive dans une occurrence d'ensemble est celle citée en argument du mot 
clé USING. Cette valeur doit bien sür étre probablement chargée en zone 
de travail. 


Il est aussi possible de sélectionner le propriétaire de l'occurrence 
courante d'un ensemble par l'instruction : 


FIND OWNER WITHIN nom-d'ensemble 





Une telle instruction permet en général de passer depuis un membre d'un 
ensemble à un propriétaire, donc de remonter les arcs du graphe des 
types d'une base de données CODASYL. 


Finalement, il est aussi possible de tester des conditions concernant 
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l'appartenance de l'article courant d'un programme à un ensemble 
(OWNER, MEMBER ou plus généralement TENANT) par l'instruc- 
tion : 


OWNER 
IF [NOT] [nom-d'ensemble] MEMBER 
TENANT 


On peut aussi tester si un ensemble est vide par : 
IF nom-d'ensemble IS [NOT] EMPTY 


3.3.4. — Le positionnement du curseur du programme 


programme : on dit que le programme navigue dans la base CODASYL 
[Bachman 73]. Aprés des navigations successives, il peut étre utile de 
revenir se positionner sur l'article courant d'un type d'article d'un fichier 
ou d’un ensemble. Ceci peut être fait à l’aide de l'instruction : 


nom-de-fichier 
nom-d'ensemble ] 


FIND CURRENT [nom-d'article] [ WITHIN { 


Cette instruction a donc pour effet de forcer le curseur du programme à 
(celui du nom-d'article, du. fichier ou de l'ensemble choisi. 


3.4. = Les échanges d'articles 


L'article pointé par le curseur d'un programme peut être amené en 
zone de travail à l'aide de l'instruction : 


[Type-d'article] 
GET 


[Nom-de-donnée]... 


Les arguments peuvent être, soit le type d'article qui doit dans ce cas être 
le même que celui de l’article pointé par le curseur du programme, soit 
une liste des données du type de l'article courant que l'on souhaite ame- 
ner en zone de travail. 


Le rangement d'un article dans la base s'effectue, aprés chargement 
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de l'article en zone de travail, par exécution de l'instruction : 
STORE type d'article [ RETAINING CURRENCY FOR 


MULTIPLE 
REALM ] 
RECORD 
SETS ) 
[nom-d'ensemble]... 





L'option RETAINING permet d'éviter le déplacement de curseurs de 
maniére identique au FIND. 


3.5. — Les mises à jour d'articles 


3.5.1. — Suppression d'articles 
La suppression de l'article courant d'un programme s'effectue par : 
ERASE [ALL] [type-d'article]. 


Si cet article est propriétaire d'occurrences d'ensemble, tous ses descen- 
dants sont également supprimés seulement dans le cas où le mot clé ALL 
est précisé, Le type d'article permet optionnellement au systéme de véri- 
fier le type de l'article courant à détruire. 


3.5.2. — Modification d'articles 


La modification de l'article courant d'un programme s'effectue à 
l'aide de l'instruction : 


[type-d'article] 
MODIFY [ | INCLUDING | 
[nom-dé-donnée]... ONLY 
ALL 
| | MEMBERSHIP ] 
[nom-d'ensemble]... 


Les données à modifier peuvent être précisées ou non ; dans le dernier 
cas, le systéme modifie toutes celles qui sont changées dans l'article en 
zone de travail. On doit aussi préciser les modifications à apporter aux 
ensembles dont l'article est membre ; plusieurs options sont possibles ; il 
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est possible de demander la réévaluation, en accord avec la clause du 
schéma SET SELECTION de toutes (INCLUDING ALL) ou de certai- 
nes (INCLUDING liste de noms d'ensemble) appartenances à des occur- 
rences d'ensembles. Il est aussi possible de ne modifier aucune donnée, 
mais seulement les appartenances aux ensembles (MODIFY... 


ONLY...). 


3.5.3. — Insertion et suppression de l'article courant 
dans une occurrence d'ensemble 

Deux instructions permettent d'insérer et d'enlever l'article courant 
d'un programme d'une occurrence d'ensemble : 

CONNECT [Type d'article] TO nom-d'ensemble. 

DISCONNECT [Type d'article] EROM nom-d'ensemble. 
Leur utilisation nécessite que le mode d'insertion dans l'ensemble ait été 
défini comme manuel (MANUAL) ou alors que l'appartenance à 
l'ensemble soit optionnelle (OPTIONAL). 


3.6. — Le contróle des fichiers 


Avant de travailler sur un fichier, un programme doit l'ouvrir en 
spécifiant le mode de partage souhaité ; cette ouverture s'effectue à 
l'aide de l'instruction : 

READY [nom-de-fichier [USAGE-MODE IS 


EXCLUSIVE RETRIEVAL J] 
PROTECTED UPDATE 


En fin de travail sur un fichier, il est nécessaire de le fermer à Paide de 
Pinstruction : 


FINISH [nom-de-fichier]... 


3.7. — Quelques exemples de transactions 


Nous avons ci-dessous illustré différents types d'accès réalisés par 
des transactions simples. Ces transactions utilisent le sous-schéma Client 
de la figure V1.6. La signification des transactions est donnée en légende 
de la figure. 
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READY F-BUVEURS USAGE-MODE PROTECTED RETRIEVAL. 
MOVE *100' TO NB IN BUVEURS. 

FIND ANY BUVEURS. 

PRINT NOM, PRENOM IN BUVEURS. 

FINISH F-BUVEURS. 


Fig. VI.7. — Accès sur clé calculée unique 
(nom et prénom du buveur de numéro 100) 


READY F-BUVEURS, F-COMMANDES. 
FIND FIRST BUVEURS WITHIN F-BUVEURS. 
PERFORM UNTIL "FIN-DE-FICHIER" 
GET BUVEURS. 
PRINT NOM, PRENOM IN BUVEURS. 
FIND FIRST COMMANDE WITHIN ACHETE. 
PERFORM UNTIL "FIN-D'OCCURRENCE-D'ENSEMBLE" 
GET COMMANDES. 
PRINT QUANTITE, DATE IN COMMANDE. 
FIND NEXT COMMANDE WITHIN ACHETE. 
END-PERFORM. 
FIND NEXT BUVEURS WITHIN F-BUVEURS. 
END-PERFORM. 
FINISH. 


Fig. VI.8. — Accès séquentiel à un fichier et à des occurrences d'un ensemble 
(Nom et Prénom de chaque buveur et liste des commandes) 


READY F-BUVEURS, F-COMMANDES. 
MOVE ‘100’ TO NB IN BUVEURS. 
FIND ANY BUVEURS. 
MOVE '10-02-81' TO DATE IN COMMANDES. 
FIND COMMANDE WITHIN ACHETE USING DATE. 
PERFORM UNTIL "PLUS-DE-COMMANDE" 
GET COMMANDE. 
PRINT QUANTITE, DATE IN COMMANDE. 
FIND DUPLICATE WITHIN ACHETE USING DATE. 
END-PERFORM. 
FINISH. 


Fig. VI.9. — Accés associatif dans une occurrence d'ensemble 
(Liste des commandes du buveur 100 passées le 10-02-82) 
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READY F-BUVEURS, F-COMMANDES. 
FIND FIRST ABUS WITHIN F-BUVEURS. 
PERFORM UNTIL « FIN-DE-FICHIER » 
GET ABUS. 
IF QUANTITE IN ABUS > 100 
FIND OWNER WITHIN BOIT. 
IF ACHETE IS NOT EMPTY 
GET BUVEURS. 
PRINT NOM, PRENOM IN BUVEURS. 
END-IF. 
END-IF. 
FIND NEXT ABUS WITHIN F-BUVEURS. 
FINISH. 


Fig. VI.10. — Accès au propriétaire et utilisation d'une condition 
(nom et prénom des buveurs ayant bu un vin en quantité supérieure à 100 
et ayant passé une commande) 


READY F-BUVEURS, F-COMMANDES. 
MOVE *100' TO NB IN BUVEURS. 
FIND ANY BUVEURS. 

ERASE ALL BUVEURS. 

FINISH. 


Fig. VI.11. — Suppression d'un article et de ses descendants 
(Suppression du buveur 100, de ses commandes et de ses boissons) 


READY F-BUVEURS. 

MOVE ‘7’ TO I. 

MOVE '200' TO NB IN BUVEURS. 
FIND ANY BUVEURS. 

FIND | ABUS IN BOIT. 

GET ABUS. 

ADD 10 TO QUANTITE IN ABUS. 
MODIFY ABUS. 

FINISH. 


Fig. VI.12, — Exemple de modification d'un article 
(Ajout de 10 à la 7* quantité de vin bu par le buveur 200) 
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4. LE MODÈLE HIÉRARCHIQUE 


Les bases de données modélisent des informations du monde réel. 
Puisque le monde réel nous apparaît souvent au travers de hiérarchies, il 
est normal qu'un des modéles les plus répandus soit le modéle hiérarchi- 
que. Beaucoup de systémes sont encore basés sur ce modéle [MRI 72, 
IBM 75]. Le lecteur trouvera une présentation détaillée du modèle hié- 
rarchique dans [Tsichritzis 76]. 


4.1. — Les concepts du modèle 


Le modèle hiérarchique est basé sur les concepts de champ et segment 
qui permettent de modéliser les objets. 


Notion 10 : Champ (Field) 
Plus petite unité de données possédant un nom. 


Un champ est exactement l'équivalent d’un atome du modèle réseau. 


Notion 11 : Segment (Segment) 
Collection de champs rangés consécutivement dans la base, portant un nom et constituant 
l'unité d'échange entre la base de données et les applications. 
Une occurrence de segment est en général de taille fixe. Les champs d'un 
segment sont tous au méme niveau. 


Les segments sont reliés par des associations [1:N] qui a un segment 
pére font correspondre N segments fils (N est un entier quelconque), 
aussi bien au niveau des types qu'au niveau des occurrences. A partir 
d'une descendance de segments reliés par des associations pére-fils, on 
construit des arbres de segments. 


Notion 12 : Arbre de segments (Tree ou record) 
Collection de segments reliés par des associations pére-fils organisée sous forme d'une 
hiérarchie. 


Un arbre de segment peut être considéré au niveau des types où un type 
racine possède n types fils qui a leur tour possèdent chacun plusieurs 
types fils. On peut aussi considérer une occurrence d’un arbre de seg- 
ment où une occurrence d’un segment racine possède plusieurs occurren- 
ces de segments fils. Parmi ceux-ci, certaines sont d’un premier type, 
d'autres d’un deuxième... etc. A leur tour les occurrences des fils peu- 
vent avoir des fils. 
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Finalement, une base de données hiérarchique peut être considérée 
comme un ensemble d’arbres, encore appelé forêt, dont les nœuds sont 
des segments. 


is 13 : Base de données hiérarchique (Hierarchical data base) 
Base de données constituée par une forêt de segments. 

La définition s’applique aussi bien au niveau des types qu’au niveau des 
occurrences. 


Une représentation par un graphe d’une base de données hiérarchi- 
que découle de la définition. Les nœuds du graphe sont bien sûr les seg- 
ments alors que les arcs représentent les associations pére-fils ; ces arcs 
sont orientés du pére vers le fils. Il est possible de considérer un graphe 
des types ou un graphe d’occurrences. Les deux graphes sont bien sür des 


forêts. 


Afin d'illustrer, nous avons défini une base de données hiérarchique 
à partir de la base vinicole. Il n'est évidemment pas possible de représen- 
ter un réseau d'association tel que défini figure VI.2. Afin de ne pas per- 
dre d'informations, on est conduit à dupliquer certaines données, par 
exemple le cru du vin dans les segments ABUS et le nom du buveur dans 
les segments COMMANDES (Champ CLIENT). Du fait que les seg- 
ments ne sont pas hiérarchiques, l'article VINS doit être éclaté en deux 
segments CRUS et MILLÉSIMES. Ainsi, une représentation hiérarchi- 
que de la base vinicole est schématisée figure VI.13. 





COMMAN 
DES 


Fig. VI.13. — Une représentation hiérarchique 
de la base vinicole (graphe des types) 


Certains modéles hiérarchiques autorisent les liens entre arbres afin 
de permettre de modéliser des associations 1 à N sans avoir à dupliquer 
des segments. On aboutit alors à des modèles hiérarchiques étendus dont 
les possibilités se rapprochent de celles du modèle réseau [IBM 75, 
Bouille 78]. 
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4.2. — Introduction au langage DL1: 


DLI est un langage de manipulation de bases de données hiérarchi- 
ques proposé par IBM [IBM 75]. Nous allons ci-dessous en donner quel- 
ques principes afin d'illustrer la manipulation de bases hiérarchiques. 


Tout d'abord, un ordre de parcours des arbres de la racine vers les 
fils, et de gauche à droite est imposé. Plus précisément, cet ordre est 
défini comme suit : 

1. Visiter le segment considéré s'il n'a pas déjà été visité. 

2. Sinon, visiter le fils le plus à gauche non précédemment visité s’il en 
existe un. 

3. Sinon, si tous les descendants du segment considéré ont été visités, 
remonter à son pére et aller à 1. 


Cet ordre de parcours des arbres est illustré figure VI.14 sur une forét 
d'occurrences de l’un des arbres des types de segments de la base vini- 
cole. Une telle forét est supposée avoir une racine virtuelle de tous les 
arbres afin de permettre le passage d'un arbre à un autre. 





Fig. VI.14. — Ordre de Parcours des arbres 


Pi 


occurrence de producteurs mijk 
Cij 


occurrence de crus dijk 


occurrence de millésime 
occurrence de commandes 


"oa 


DL. est aussi un langage de manipulation navigationnel, en ce sens 
que des curseurs permettent de mémoriser un positionnement sur la 
base. Ces curseurs, appelés PCB, sont stockés dans des Structures de 
données passées en arguments des appels DL] effectués comme des 
appels de procédures (CALL). Les PCB permettent en particulier de 
mémoriser des positionnements sur la base de données (adresses de seg- 
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ments). lis permettent aussi de récupérer un code réponse STATUS du 
système après chaque appel. 


Une qualification de chemin peut être associée à un appel DL1. Une 
telle qualification se compose d'une suite de qualifications de segments 
(Search Segment Argument) ; une qualification de segment est une struc- 
ture PL1 de la forme approximative : 


01 SSA/*(Qualification de segments)*/ 

02  NOM-DE-SEGMENT 

02 CODE-COMMANDE /*(spécifiant diverses options possibles)*/ 
02 NOM-DE-CHAMP 

02 OPÉRATEUR-DE-COMPARAISON /*(«, x, >, z, =, #)*/ 

02 VALEUR 

02 CONNECTEUR /*(AND, OR)*/ 


Un ensemble de qualification de segments constituant une qualification 
de chemin doit spécifier un chemin depuis la racine jusqu'au segment 
cherché dans un arbre du graphe des types. 


A partir de ces éléments (PCB et qualification de chemin), diffé- 
rents types d'appels peuvent étre effectués : 


— GET UNIQUE (GU) permet de rechercher directement la premiére 
occurrence de segment satisfaisant la qualification. Le PCB passé en 
argument est utilisé pour mémoriser la clé de ce segment ; son contenu 
est chargé en mémoire. 


— GET NEXT (GN) permet de rechercher l'occurrence de segment sui- 
vant celle mémorisée dans le PCB (en général la derniére trouvée) satis- 
faisant la qualification si elle existe. 


— GET NEXT WITHIN PARENT (GNP) à la méme fonction que 
GET NEXT, mais il autorise la recherche seulement à l'intérieur des des- 
cendants du segment courant. 


— INSERT (ISRT) permet d'insérer un nouveau segment en-dessous le 
parent sélectionné par la qualification. 


— DELETE (DLET) permet de supprimer l'occurrence du segment 
courant (qui a dû être précédemment accédé par une instruction spéciale 
du type GET HOLD...). 


— REPLACE (REPL) permet de modifier l'occurrence du segment 
courant (qui a dû être précédemment accédé par une instruction spéciale 
du type GET HOLD...). 
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4.3. — Quelques exemples de transactions 


Nous avons ci-dessous illustré quelques types d'accés par des tran- 
sactions simples. La syntaxe utilisée est trés loin de la syntaxe pénible de 
DLI [IBM 75]. 


I*DECLARATIONS*/ 


DCL 1 ` SSA 
2 SEGMENT = 'BUVEURS' 
2 CHAMP = 'NB' 
2 OPERATEUR = ‘= 
2 VALEUR = ‘100’ 
DCL 1 PCB 
2 STATUS 
«PROGRAMME! 


GU (PCB, BUVEUR, SSA) 
PRINT BUVEUR. NOM, BUVEUR. PRENOM 


Fig. VI.15. — Accès sur clé (Nom et prénom du buveur 100) 


I*DECLARATIONS*/ 


DCL 1 SSA1 
SEGMENT 
CHAMP 
OPERATEUR 
VALEUR 


SSA2 
SEGMENT 
CHAMP 
OPERATEUR 
VALEUR 


PCB 


2 STATUS 


‘PRODUCTEURS 
‘NOM’ 


‘MARTIN’ 


How oH M 


DCL 
'CRUS' 
'CRU' 


Won n 


‘BEAUJOLAIS’ 


+ PMNP- ND D ND 


DCL 


I* PROGRAMME Y*/ 
GU (PCB, CRUS, SSA1, SSA2) 
WHILE STATUS +  'Fin-de-descendance' 
GNP 
PRINT "segment lu" 
END-WHILE 


Fig. VI.16. — Balayage des descendants d'un segment 
(Millésime et commandes de Beaujolais produit par Martin) 
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I*DECLARATIONS+/ 
DCL 1 — SSA1 
2 SEGMENT = ‘PRODUCTEURS 
2 CHAMP = ‘NOM’ 
2 OPERATEUR == 
2 VALEUR = ‘MARTIN’ 
DCL 1  SSA2 
2 SEGMENT = CRUS 
2 CHAMP = 'CRU' 
2 OPERATEUR =: 
2 VALEUR = 'BEAUJOLAIS' 
DCL 1  SSA3 
2 SEGMENT = 'COMMANDES' 
2 CHAMP = DATE 
2 OPERATEUR ='>' 
2 VALEUR = 40.02.87 
2 CONNECTEUR = 'AND' 
2 CHAMP = ‘CLIENT’ 
2 OPERATEUR == 
2 VALEUR = ‘DUPONT: 
DCL 1 PCB 
2 STATUS 
I*PROGRAMME*/ 


GHU (PCB, COMMANDES, SSA1, SSA2, SSA3) 
COMMANDES. QUANTITE = COMMANDES. QUANTITE + 100 
RPL 


Fig. VI.17. — Mise à jour d'un segment (ajout de 100 à la quantité 
de la commande de Beaujolais expédiée à MARTIN par DUPONT le ‘10-02-81 V] 


5. COMPARAISON DES PRINCIPAUX MODÈLES 


Un modèle de données peut être vu comme un ensemble d'outils 
permettant de constituer des objets complexes et de les associer, à partir 
d'objets atomiques que constituent les valeurs simples. Les outils fournis 
par les modèles étudiés (relationnel, réseau, hiérarchique) peuvent être 
obtenus à l'aide de deux opérations : 


— l'abstraction [Smith 77] consiste à regrouper des objets en une collec- 
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tion désignée par un nom ; cette opération peut être réalisée sur des 
objets différents : il s’agit alors d’une agrégation ; elle peut aussi être 
réalisée sur des objets identiques : il s’agit alors d’une généralisation. 


— l'association [Chen 76] consiste à mettre en relation des objets appar- 
tenant à des collections différentes ou identiques. Des associations entre 
n types d’objets sont dites n-aires. Des associations entre deux types 
d'objets sont dites binaires (= 2-aires). En particulier, les associations 
binaires sont caractérisées par les nombres maximum d'objets des deux 
collections qui peuvent être associés (cardinalités maximum des associa- 
tions). On distingue ainsi les associations [1 : n], qui associent un objet 
de la premiére collection à n objets de la deuxiéme, des associations 
[k : n], qui permettent d'associer k objets de la premiére collection à n 
objets de la deuxiéme (k et n étant des entiers positifs quelconques). 


Les deux opérations d'abstraction et d'association sont différentes 
en ce sens qu'un objet résultant d'une abstraction ne peut exister dans la 
base que si les objets composants existent. Par contre, une association 
peut exister dans la base entre deux objets non encore stockés dans la 
base. 


Un modéle de données peut étre caractérisé par le nombre de 
niveaux d'abstractions qu'il permet, c'est-à-dire le nombre d'abstrac- 
tions successives nécessaires pour composer les objets du modéle. Il peut 
aussi être caractérisé par les types d'associations qu'il supporte. 


Ainsi, le modéle relationnel permet deux niveaux d'abstraction : 
agrégation de valeurs pour composer des tuples et généralisation pour 
composer une relation. Le modèle réseau et le modèle hiérarchique per- 
mettant un nombre quelconque k d'abstractions par empilement hiérar- 
chique d'agrégats ou de segments afin d'obtenir des articles ou des arbres 
de segments, selon le modèle. 


Du point de vue association, le modéle relationnel supporte des 
associations n-aires alors que le modéle réseau les supportent mal ; nous 
préférons pour notre part considérer qu'il supporte des associations 
binaires. Un modéle purement hiérarchique ne supporte aucune associa- 
tion puisque les arbres sont obtenus par abstraction. Des extensions du 
modéle hiérarchique permettent les associations binaires entre arbres 
[IBM 75]. Du point de vue cardinalité des associations binaires, le 
modèle réseau ne supporte que des associations [1 : n] alors que le 
modèle relationnel supporte des associations [k : n]. 


Les résultats de comparaison obtenus du point de vue niveaux de 
généralisation et types d'associations sont résumés figure VI.18. Nous 
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n'avons pas fait figurer là le modèle Entite-Association [Chen 76] qui 
n'est qu'en fait un enrichissement par le vocabulaire et le graphisme du 
modéle relationnel, enrichissement trés utile aux concepteurs. 


















Modèle Abstraction Association 
Modéle Relationnel 2 niveaux n-aires [k : n] 
Modèle Réseau n niveaux binaires [1 : n] 
Modèle Hiérarchique n niveaux — 











Fig. VI.18. — Comparaison des possibilités d'abstraction et d'association des modèles 


6. CONCLUSION 


Dans ce chapitre, nous avons présenté les principaux modèles 
d’accès, c’est-à-dire ceux directement issus de la modélisation d'organi- 
sation d'articles stockés dans des fichiers et reliés entre eux par des poin- 
teurs. Compte tenu de l'accroissement des possibilités des machines, ces 
modèles sont aujourd’hui critiqués en temps que modèles conceptuels ou 
externes de données. Ils peuvent rester trés compétitifs au niveau interne. 
Les critiques proviennent sans doute aussi de la complexité des langages 
de manipulation historiquement associés à ces modèles, basés sur la navi- 
gation. Cependant, il est tout à fait possible de définir des langages asser- 
tionnels basés sur la logique des prédicats pour un modéle hiérarchique 
ou réseau. 


Finalement, la question se pose de savoir si le modèle relationnel (ou 
son dérivé, le modèle entité-association) est un bon candidat pour consti- 
tuer un modéle conceptuel. Nous conclurons d'aprés [Codd 79] qu'un 
modèle qui doit être un cadre conceptuel pour définir une large classe de 
bases de données structurées et un médiateur entre des représentations de 
données stockées et des vues usagers, devrait probablement avoir au 
moins quatre caractéristiques : 


1. permettre une représentation sous forme de tableaux des données, 
2. permettre une interprétation ensembliste afin d'autoriser des opéra- 
teurs similaires à ceux de l’algèbre relationnelle, 
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3. permettre une interprétation des objets en termes de formules de la 
logique des prédicats afin de faciliter les inférences de connaissan- 
ces, 

4. supporter une représentation graphique afin de pouvoir visualiser les 
objets et leurs associations pour concevoir la base. 


Ajoutons également que la simplicité est une caractéristique essen- 
tielle d'un modéle. C'est là un des avantages déterminant du modéle 
relationnel qui, dans sa version entité-association, possède aussi les qua- 
tre caractéristiques précédentes. 
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VII. LE CONTRÔLE 
DES ACCÈS CONCURRENTS 


1. INTRODUCTION 


Le contróle de concurrence est la partie du systéme de gestion de 
base de données qui contróle l'exécution simultanée de transactions de 
sorte à produire les mémes résultats qu'une exécution séquentielle. 
Autrement dit, le contróle de concurrence rend le partage des données 
complétement transparent pour l'usager. Il est facile de réaliser un 
SGBD avec un contróle de concurrence simple mais inefficace, consis- 
tant par exemple à verrouiller la base de données toute entiére pendant 
l'exécution de chaque transaction ; les performances d'un tel systéme se 
dégraderaient rapidement avec l'augmentation du nombre d'usagers de 
facon à devenir complétement inacceptable. Aussi, les concepteurs de 
systémes ont cherché des algorithmes simples mais efficaces qui permet- 
tent un haut degré de concurrence de facon à atteindre un niveau de per- 
formance satisfaisant. Il est important de prouver la validité des méca- 
nismes proposés car le contróle de concurrence est un probléme com- 
plexe qui a donné beaucoup de solutions partielles ou incorrectes. 


Dans ce chapitre, nous présentons les principales techniques de 
contróle de concurrence ainsi que leurs justifications. Pour cela, le cha- 
pitre est divisé en six sections. La section 2 présente certaines définitions 
clés concernant l'intégrité des données ; elle décrit aussi comment l'exé- 
cution simultanée de transactions dans un systéme de bases de données 
peut conduire à des pertes d'opérations ou à l'incohérence de la base de 
données. La section 3 analyse les conditions d'une exécution sans conflit 
de concurrence. Basés sur ces principes, deux types de contróle de 
concurrence sont présentés respectivement dans les sections 4 et 5. La 
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première approche appelée ordonnancement initial par estampillages 
comporte deux phases : (1) ordonner et estampiller par un numéro les 
transactions avant leurs exécutions, (2) vérifier que les accès conflictuels 
sont effectués dans l’ordre donné ; si deux transactions ne respectent pas 
cet ordre alors l’une d'elles est reprise. L'approche suivante, appelée ver- 
rouillage deux phases, dérive de la méthode classique d’allocation des 
ressources à des processus. Ainsi, certaines parties des données peuvent 
être considérées comme des ressources qui sont allouées progressivement 
(verrouillées) puis désallouées (déverrouillées) aux transactions. Cette 
méthode souléve le probléme bien connu du verrou mortel. Finalement, 
d'autres méthodes possibles sont envisagées dans la section 6. 


2. DÉFINITION 


2.1. — Intégrité des Données 


Dans une base de données accédée par des processus concurrents, 
un des problémes essentiels est d'assurer la concordance des données 
avec le monde réel que la base modélise et obtenir ainsi une base de don- 
nées cohérente. Nous allons d'abord définir cette derniére notion d'une 
facon plus formelle. Le schéma d'une base de données contient la des- 
cription des données ainsi que les contraintes d'intégrité auxquelles doi- 
vent obéir les données. 


Notion 1 : Contrainte d'intégrité (Integrity Constraint) 
Assertion qui doit être vérifiée par des données à des instants déterminés. 


Base de données dont l'ensemble des contraintes d'intégrité (explicites ou implicites) est res- 


| Notion 2: Base de données cohérente (Consistent database) 


pecté par les données de la base. 


Il existe plusieurs types de contraintes d'intégrité. Afin d'illustrer 
ces différents types de contraintes, nous utiliserons la base relationnelle 
représentée figure VII.1. Cette base de données modélise sommairement 
un magasin classique stockant, vendant et achetant des produits. 


Tout d'abord, une contrainte d'intégrité peut porter sur une donnée 
unique. La définition d'un type de donnée élémentaire permet souvent 
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d’exprimer de telles contraintes, par exemple : 

— Contraintes de domaine de variation (exemple : la donnée quantité 
achetée est un nombre entier), 

— Contraintes de plage de valeur (exemple : la donnée quantité vendue 
doit être comprise entre 1 et 1 000). 


N° de produit 
Date d'achat 


Y | ccm achetée 


ACHAT (NP, DA, QA) 





N? de produit 
Date de vente 


Quantité vendue 
Y Y ïY 


VENTE (NP, DV, QV) 











N° de produit 
Quantité en stock 


£4— — — 


STOCK INP, QS) 


N° de produit 
Nom du produit 
Nom du fournisseur 


i F Nom du fabricant 


PRODUIT (NP, NOMP, NOMFO, NOMFA) 


Fig. VII.1. — Exemple de Base de Données 


Une contrainte d’intégrité peut également porter sur plusieurs don- 
nées. De telles contraintes peuvent être des contraintes de dépendances 
entre données : 


— Dépendances fonctionnelles, telles que numéro de produit détermine 
nom du produit (NP — NOMP). 

— Dépendances multivaluées, telles que numéro de produit multi-déter- 
mine nom du fournisseur indépendamment du nom du fabricant éga- 
lement multi-déterminé par le numéro du produit (NP -—— NOMFO 
et NP >+ NOMFA). 
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— Dépendances d'inclusions telles que le fait que tout tuple de la rela- 
tion STOCK doit correspondre à un tuple dans la relation PRO- 
DUIT : on parle encore de dépendances existentielles ou référentiel- 
les dans le cas particulier d’inclusions de clés de relations. 

— Contraintes arithmétiques que doivent vérifier certaines données ; 
par exemple, pour chaque produit la quantité en stock QS doit rester 
égale à la somme des quantités achetées moins la somme des quanti- 
tés vendues (QS = E QA - X QV). Un cas particulier de telles 
contraintes sont les contraintes de duplication telles que A — B, qui 
permettent de générer des copies multiples d'une méme donnée. 

— Un autre type important de contraintes d'intégrité est constitué par 
certaines valeurs invariantes non explicités dans la base. Par exemple, 
la somme des avoirs contenus dans une base de données bancaire doit 
rester constante lors de l'exécution d'un transfert. 

— ]lest enfin à remarquer que certaines contraintes d'intégrité peuvent 
être dépendantes du temps et par exemple seulement vraies en fin de 
semaine ou en fin de mois ; on parle alors de contraintes d'intégrité 
temporelles. 


Il est important de noter que toutes les contraintes d'intégrité (à l'excep- 
tion des contraintes temporelles) auxquelles est soumise une base de don- 
nées peuvent étre exprimées à l'aide de la logique des prédicats du pre- 
mier ordre. 


2.2. — Notion de transaction 


Lorsqu'un traitement est appliqué à une base de données, en général 
celle-ci passe par des états transitoires durant lesquels certaines 
contraintes d'intégrité ne sont plus vérifiées. Afin d'isoler des unités de 
traitement respectant la cohérence de la base de données, on introduit la 
notion de transaction. 


Notion 3 : Transaction (Transaction) 
Unité de traitement séquentiel, exécutée pour le compte d'un usager qui, appliquée à une 
base de données cohérente, restitue une base de données cohórente. 


Les contraintes d'intégrité sont donc toujours des invariants pour les 
transactions. Un systéme de base de données exécute en général un 
ensemble de transactions simultanément pour différents usagers. Les 
problèmes de concurrence sont soulevés par les interférences qui peuvent 
survenir entre ces diverses transactions du fait des données partagées. 


Les données sont donc mises à jour par des unités de traitement res- 
pectant la cohérence de la base de données, appelées transactions. Une 
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| 
| 
| 


174 Bases de données 


transaction est composée d’unités de traitement plus fines appelées 
actions. 


[Toto 4 : Action (Action) 
Commande indivisible exécutée pour le compte d'une transaction par le système. 


A titre d'exemple, la lecture d'une donnée en mémoire (READ x — 
Xj), ou son écriture dans la base WRITE X, — X sont généralement des 
actions. 


2.3. — Problèmes de concurrence 


2.3.1. — Pertes d'opérations 


Un premier exemple bien connu de problémes soulevés par l'exécu- 
tion simultanée de transactions est la perte d'opération. Le cas le plus 
typique est la perte de mise à jour. Ce probléme résulte du fait qu'une 
transaction peut, lors de l'exécution d'une action ai, lire un objet dans 
un tampon lui appartenant puis modifier cet objet (voire simplement le 
réécrire) lors d'une action aj (j > i) à partir des valeurs précédemment 
lues, alors qu'une mise à jour ak de cet objet a été accomplie par une 
autre transaction entre les actions ai et aj. Dans ce cas, la mise à jour ak 
est perdue. Une telle situation est représentée figure VII.2. Un problème 
similaire est la confusion d'identité qui peut survenir lorsqu'une transac- 
tion conserve une référence à une donnée détruite par une autre transac- 
tion [Engles 76]. 


Transaction T1 Transaction T2 
aj : Read X =» x1 = 
ak : Read X= x2 
X2 1x2 
Write x2 => X 
aj: x1 + 1 —2x1 


Write xq —- X 


Temps 


Fig. VIL2. — Exemple de perte d'opération 
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2.3.2. — Inconsistances 


Un deuxiéme type de probléme est soulevé par l'existence de 
contraintes d'intégrité. Ce probléme, appelé inconsistance, survient cha- 
que fois qu'une transaction observe ou pire modifie un état transitoire de 
la base de donnée, état caractérisé par le fait qu'une contrainte d'inté- 
grité n'est pas vérifiée [Eswarar 76]. Un premier exemple d'inconsis- 
tance est représenté figure VII.3. A et B sont deux données qui doivent 
vérifier la contrainte À = B. La transaction T2 observe A aprés qu'elle 
ait été modifiée par T1 et B avant qu'elle ait été modifiée par T1. Ainsi, 
T2 imprime une valeur pour A différente de celle de B. 


A=B 
T1 T2 
Read A = H1 
aj +1 — 84 
Write a1 — A 
Read A — a2 
Print a2 
Read B > b2 
Print bo 
Read B —- b 
61 +1 _> bł 
Write b4 — B 
Temps 


Fig. VII.3. — Exemple d'observation d'inconsistances 


Un deuxiéme exemple plus grave puisqu'il provoque la destruction 
de la base de données est représenté figure VII.4. Là, T2 met à jour un 
état transitoire incohérent caractérisé par A = B. 


T1 A=B T2 
Read A —+ 81 
a +1 —- aj 
Write a4 — A 
Read A — 82 
a2*2 — a2 
Write a2 — A 


Read B — b2 
b2*2 — b2 
Write b2 > B 

ReadB — b4 

bit 1 — bı 

Write b4 — B 


Fig. VII.4. — Exemple d'introduction 


d'inconsistances dans une base de données Temps 


| 
| 
| 
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| 
| 
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Des inconsistances peuvent aussi être produites par des transactions 
du fait de la non reproductibilité des lectures. En effet, une transaction 
peut lire deux fois une même donnée et trouver deux valeurs différentes 
du fait que la donnée a été modifiée par une transaction concurrente 
entre les deux lectures. La figure VII.5 illustre ce problème. T1 imprime 
deux valeurs différentes pour la méme donnée A. 





Ti T2 

Read A — a1 Ï 
Print a1 = 

—]- Read A —- 82 

-— 83241 —- az 

Write a2 — A 
Read A —- al 
Print a1 
Y Temps 


Fig. VII.5. — Non reproductibilité des lectures 


3. CARACTÉRISATION DES EXÉCUTIONS SANS CONFLIT 


3.1. — Concepts de base 


Un module du systéme de gestion de bases de données contróle 
l'accès des transactions à des parties de base de données appelées granu- 
les. 


Notion 5 : Contrôleur (Controller ou Scheduler) 
Module du systéme chargé de contróler les accés concurrents aux données. 


Notion 6 : Granule (Granule) 
Unité de base de données dont l'accès est contrôlé individuellement par un contrôleur. 


Le choix de la taille des granules est un probléme controversé [Ries 
77, Ries 79]. Elle peut varier depuis l'article à la base de données en pas- 
sant par la page et le fichier. Le choix d'un granule de petite taille favo- 
rise le parallélisme mais augmente le temps perdu à contróler les accés 
aux données. En pratique, il est souvent souhaitable de disposer de gra- 
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nules de taille variable, petit si la transaction accède à peu de données et 
plus grand sinon. 


Un granule obéit à des contraintes d'intégrité internes. Lors des 
modifications de la base de données, les granules sont modifiés par des 
suites d'actions constituant des unités fonctionnelles qui respectent la 
cohérence interne du granule, c'est-à-dire les contraintes d'intégrité qui 
relient les données appartenant au granule. 


Notion 7 : Opération (Operation) 
| Sue d'actions accomplissant une fonction sur un granule en respectant sa cohérence 

interne. 
Par exemple, si le granule est la page, les opérations de base sont souvent 
LIRE (page) et ECRIRE (page) qui sont dans bien des systèmes égale- 
ment des actions indivisibles. Dans le cas où le granule est l’article, des 
opérations classiques sont également LIRE (article) et ECRIRE (article) 
mais aussi MODIFIER (article) et INSERER (article). Avec ces opéra- 
tions de base, il est possible d'en construire d'autres. 


L'application d'opérations à des granules conduit à des résultats. 


Notion 8 : Résultat d'une opération (Operation result) 
| Etat du granule concerné après application de l'opération considérée ainsi que les effets de 
bords provoqués par l'opération. 
Par exemple, le résultat d'une opération LIRE est représentée par la 
valeur du tampon récepteur après exécution alors que le résultat d'une 
transaction modifiant une base de données est l'état des granules modi- 
fiés après exécution ainsi que la valeur des messages édités. 


Un système de bases de données exécute donc une suite d'actions 
résultant de transactions concurrentes. Après complétude d'un ensemble 
de transactions (T1, T2, ... Tn), une histoire du système peut être repré- 
sentée par la suite des actions exécutées. Plus généralement, toute suite 
d’actions pouvant représenter une histoire possible sera appelée simple- 
ment exécution. 


Une exécution des transactions (Ti, T», … Tn) est une séquence d'actions obtenues en inter- 


| Notion 9: Exécution de transactions (Schedule, ou Log. ou Histcry) 
classant les diverses actions des transactions Ti, T», ... Ts. 


Une exécution respecte donc l'ordre des actions de chaque transaction 
participante et est par définition, séquentielle. Par exemple, considérons 
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les transactions T, et T,, représentées figure VII.6, modifiant les données 
A et B reliées par la contrainte d'intégrité A — B ; A et B appartiennent 
à deux granules distincts, maximisant ainsi les possibilités de concur- 
rence. Une exécution de ces deux transactions est représentée figure 
VII.7. Une autre exécution est représentée figure VII.8, mais celle-là est 
inacceptable car elle conduit à une perte d'opération. 


T, T, 

Read A — a, Read À — a, 
a + 1 — a a, * 2 — 8 
Write a, — A Write a — A 
Read B - b, Read B - b, 
b +1 — b b,*2 - b 
Writeb, — B Writeb, - B 


Fig. VIL6. — Transactions T, et T; 


T;: ReadA — a, T,: ReadA — a, 
T: ati — a, Ta: a,*2 - a 
T: Writea, — A T,: ReadA - a, 
Ta: ReadA — a T: a +1 — a 
Ta: &*2 — & Ta: Writea - A 
Ta: Writea - A T,: ReadB - b, 
T,: Read B - b Ta: b,*2 - b; 
Ti: b +1 - b Ta: Writea, — A 
Ta: Writeb, — B Tı: ReadB — b, 
Ta: ReadB - b, T: b+1 — B 
Ta: b*2 - b T,: Writeb, — B 
Ta: Writeb, - B Ta: Writeb, — B 


Fig. VIL7. — Une exécution correcte Fig. VIL8. — Une exécution inacceptable 
de T; et T; de T, et T2 


3.2. — Exécution sérialisable 


Certaines exécutions introduisent des pertes d'opérations ou des 
inconsistances, comme nous l'avons vu ci-dessus. L'objectif du contróle 
de concurrence consiste à ne laisser s'exécuter que des exécutions sans 
pertes d'opérations ou inconsistances. Il est bien connu que l'exécution 


] 
| 











| 
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successive de transactions (sans simultanéité entre transactions) est un 
cas particulier d'exécution sans perte d'opérations ni inconsistances. 
Une telle exécution est appelée succession et peut être définie plus for- 
mellement comme suit. 


Notion 10 : Succession (Serial schedule) 
Une exécution E de (T1, T2 ... Tn) est une succession s'il existe une permutation IT de 
(1,2 ... n) telle que : 

E= < Tani Dee Tam > 


Afin d’assurer l’absence de conflit, il est simple de ne tolérer que les 
exécutions qui donnent le même résultat qu’une succession pour chaque 
transaction. De telles exécutions sont dites sérialisables. 


Notion 11 : Exécution sérialisable (Serializable schedule) 
Une exécution de (T1, T2 ... Tn) est sérialisable si et seulement si elle donne pour chaque 
transaction participante le même résultat qu'une succession de (T1, T2 ... Tn). 


Le probléme de contróle de concurrence est donc d'assurer qu'un 
système centralisé (ou réparti} ne peut générer que des exécutions sériali- 
sables. C'est là une condition suffisante pour assurer l'absence de conflit 
dont la nécessité peut &tre discutée [Gardarin 77]. 


3.3. — Propriétés des Opérations 


Deux opérations qui ne modifient aucune entité et qui appartiennent 
à deux transactions différentes peuvent toujours étre exécutées simulta- 
nément sans modifier les résultats de leur exécution. Autrement dit, tout 
interclassement d'opérations n'effectuant que des lectures conduit à des 
résultats identiques à une exécution successive de ces opérations. Plus géné- 
ralement, il est possible de définir la notion d'opérations compatibles. 


Notion 12 : Opérations compatibles (Compatible operations) 

Deux opérations O; et 0, sont compatibles si et seulement si quel que soit l'exécution simul- 
tanée de O, et O; le résultat de cette exécution est le méme que celui de l'exécution séquen- 
tielle de 0; suivie de O, ou de O; suivie de O, (à noter que les résultats O; puis 0j, et 0; puis 
O; peuvent être différents). 


Considérons par exemple les opérations représentées figure VII.9. 


Les opérations O, et O„ sont compatibles ; O, et O, ainsi que O, et O;;, 
ne le sont pas. 
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Il est généralement important de remarquer que deux opérations 
travaillant sur deux granules différents sont toujours compatibles. En 
effet, dans ce cas aucune perte d’opérations ne peut survenir si l’on inter- 
cale les opérations. Or, il est simple de voir que deux opéations sont non 
compatibles lorsqu'il existe une possibilité d'intercalation générant une 
perte d'opérations. 


04 On 
Read A — a, Read A — a, 
a * 2 — 8, a, + 1 — a, 
Print a, Print a; 

042 02; 
Read A — a, Read A — a, 
a, * 2 - a, a, + 1 — aa 
Write a, — A Write a, — A 

0 02 
Read A — a, Read À — a, 
a + 1 - 8, a + 10 - a, 
Write a, — A Write a, — A 


Fig. VII.9. — Exemples d'opérations 


L'ordre d'exécution de deux opérations peut changer les résultats. 
Dans d'autres cas, il peut être indifférent. Plus généralement, nous défi- 
nirons la notion d'opérations permutables, qu'il faut bien distinguer de 
celle d'opérations compatibles (la premiére est une notion indépendante 
de l'ordre d'exécution, alors que la deuxiéme est définie à partir de la 
comparaison des ordres d'exécution) [Gardarin 77]. 


Notion 13 : Opérations permutables (Permutable operations) 
Deux opérations 0, et 0, sont permutables si et seulement si toute exécution de O, suivie 
par O, donne le méme résultat que celle de O; suivie par 0j. 


Par exemple, les opérations O;, et O, représentées figure VIL.9 sont per- 
mutables alors que les opérations O, et O, ne le sont pas. Soulignons 
que deux opérations travaillant sur des granules différents sont toujours 
permutables. En effet, dans ce cas, l'exécution de la premiére ne peut 
modifier le résultat de la seconde et réciproquement. 
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3.4. — Caractérisation des exécutions sérialisables 


Afin de caractériser les exécutions sérialisables, nous introduisons 
deux transformations de base d’une exécution de transactions. Tout 
d'abord la séparation d'opérations compatibles O; et O; exécutées par 
des transactions différentes consiste à remplacer une exécution simulta- 
née de ces opérations E (O;, Oj) par la séquence donnant le même résultat 
soit < O; ; O; > ou < O; ; O, >. La séparation d'opérations permet 
donc de mettre en succession des opérations compatibles exécutées par 
des transactions différentes. Ensuite, la permutation d'opérations per- 
mutables O; et O; exécutées par des transactions différentes consiste à 
changer l'ordre d'exécution de ces opérations ; par exemple la séquence 
< O; ; Oj > est remplacée par la séquence < 0,;0; >. 


A partir des transformations précédentes, il est possible de donner 
une condition suffisante pour qu'une exécution soit sérialisable. 


THÉORÉME 1 : A 

Une condition suffisante pour qu'une exécution soit sérialisable est 
qu'elle puisse être transformée par séparation des opérations compati- 
bles et permutation des opérations permutables en une succession des 
transactions composantes. 


Preuve : 
Par définition, séparations et permutations conservent les résultats. Par 
suite, si l'exécution peut être transformée en une succession, elle donne 
le méme résultat que cette succession pour chaque transaction et est donc 
sérialisable. La condition n'est pas nécessaire car, au moins pour certai- 
nes valeurs des données, des opérations non compatibles ou non permu- 
tables peuvent étre exécutées simultanément sans conflits. 














A titre d'exemple, considérons l'exécution représentée figure VII.7. 
En représentant seulement les opérations, cette exécution S'écrit : 


Ti'A +1 — A 

T2:A*2 — A 

T1:B+1 - B 

T2:B*2 - B 
Les opérations A * 2 — Aet B + 1 — B sont permutables car elles agis- 
sent sur des granules différents. Par suite, cette exécution peut être trans- 
formée en : 
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qui est une succession de T1 puis T2. Par suite, l'exécution représentée 
figure VII.7 est sérialisable. 


3.5. — Graphe de précédence 


La notion de précédence peut &tre définie dans toute exécution sans 
opérations simultanées, par exemple obtenue aprés séparation des opéra- 
tions compatibles. 


Notion 14 : Précédence (Precedence) 

Soit S une exécution sans opération simultanée. Il y a précédence de T, par T, (T; précède 
Tj, noté T, < Tj) dans S si et seulement si il existe deux opérations non- permutables 0, et 
0, telles que O; est exécutée par T, avant O; par Tp 


A partir de la notion de précédence, il est possible de définir un graphe 
caractérisant les relations entre transactions lors d'une exécution. Le gra- 
phe de précédence d'une exécution est un graphe dont l'ensemble des 
sommets est l'ensemble des transactions et tel qu'il existe un arc de T; 
vers T; si et seulement si T; précède T; (T, < T;). 


Il est possible de démontrer le théoréme suivant : 


THÉORÈME 2 : 
Une condition suffisante pour qu'une exécution soit sérialisable est que 
le graphe de précédence associé soit sans circuit. 


Preuve : 
Le graphe de précédence représente les relations de précédence entre opé- 
rations non permutables. A partir de ce graphe sans circuit, il est possible 
de définir un ordre partiel des transactions respectant les relations de 
précédence entre opérations non permutables. Cet ordre partiel peut être 
complété arbitrairement en un ordre total : T, ; T ; ... TÔ. Toutes les 
opérations ne respectant pas cet ordre dans l'exécution sont permuta- 
bles. Par permutation de ces opérations, il est donc possible de ramener 
l'exécution à la succession < Tj ; To ; ... Ta >. La condition n'est pas 
nécessaire pour les mémes raisons qu'au théoréme 1. 














A titre d'illustration du théoréme 2, le graphe de précédence corres- 
pondant à l'exécution représentée figure VII.7 est représenté figure 
VII.10. Ce graphe est sans circuit, ce qui confirme que l'exécution consi- 
dérée est sérialisable. 
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Par contre, l’exécution et le graphe de précédence correspondant repré- 
sentés figure VII.11 sont respectivement non sérialisable et avec circuit. 


Fig. VIL10. — Exemple de graphe de précédence sans circuit 


Ti:A+1 — A 
T2:A+2 — A 
T2:B*2 - B 
T:Be1 - B 


Fig. VIL11. — Exemple de graphe de précédence avec circuit 


Un cas particulier important d'opérations est obtenu lorsque le gra- 
nule est choisi égal à une page. Dans ce cas, les deux opérations de base 
qui permettent d'effectuer une fonction cohérente sur une page de la 
base de données sont : 


(1) READ Page 
(2) WRITE page. 


A noter que dans ce cas particulier, ce sont également très souvent des 
actions indivisibles pour le systéme transactionnel. Plus généralement, 
chaque fois que la notion de granule coincide avec l'unité d'échange 
entre la base de données et la transaction, il est possible de considérer 
que READ (granule) et WRITE (granule) sont des opérations de base 
permettant de composer toutes les autres. Afin d'éviter les conflits, le 
systéme transactionnel doit assurer la séparabilité de ces opérations de 
base : ceci est généralement fait au moyen de mécanismes de synchroni- 
sation type sémaphores permettant d'exclure l'exécution simultanée des 
opérations READ/WRITE sur un méme granule. Dans la suite, afin de 
simplifier et sauf indications contraires, nous considérons donc le cas des 
systèmes pratiques où il existe deux opérations de base READ (granule) 
et WRITE (granule) qui sont toujours séparées lorsqu'elles portent sur 
un méme granule. 


Dans le cas des systémes pratiques, toute séparation puis permuta- 
tion d'opérations portant sur des granules différents sont possibles. Seu- 
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les en fait, certaines permutations d’opérations portant sur un même gra- 
nule sont impossibles. Plus précisément : 


— (T, - READ g) (T; - WRITE g) ne sont pas des opérations permuta- 
bles ; en conséquence, dans le cas où T; lit un granule avant que T; 
Pécrive, T, précède T;. 

— (T, - WRITE g) (T; - READ g) ne sont pas non plus des opérations 
permutables ; en conséquence, dans le cas où T; écrit un granule avant 
que T; le lise, T; précède T). 

— (T, - WRITE g) (T; - WRITE g) ne sont pas non plus des opérations 
permutables ; en conséquence, dans le cas où T; écrit un granule avant 
que T; l’écrive, également T; précède T;. 


Dans la suite, nous allons étudier divers algorithmes de contróle des 
accés concurrents, Nous prouverons leur correction à partir du théoréme 
2 appliqué aux précédences READ/WRITE, WRITE/READ et 
WRITE/WRITE. 


4. ALGORITHMES BASES SUR L'ORDONNANCEMENT INITIAL 
DES TRANSACTIONS 


4.1. — Estampilles de transactions 


Une premiére méthode pour empécher la production d'une exécu- 
tion non sérialisable consiste à ordonner les transactions lors de leur lan- 
cement en exécution et à contróler que les accés conflictuels aux granules 
s'effectuent dans l’ordre défini ; c'est la méthode de base pour le contró- 
le de concurrence dans SDD.1 [Bernstein 78]. Pour cela, il est nécessaire 
d'associer à chaque transaction une référence unique, appelée estampille 
de transaction, permettant de repérer l'ordre choisi. 


Notion 15 : Estampille de transaction (Transaction timestamp) 
Valeur numérique affectée à une transaction et permettant d'ordonner cette transaction 
par rapport aux autres transactions. 


Dans un systéme centralisé, les estampilles de transactions peuvent être 
simplement générées à partir d’un compteur. Ceci est plus difficile dans 
un système réparti. 
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4.2. — Estampilles de granules 


Afin de contrôler que les transactions opèrent sur les granules dans 
le même ordre que celui défini par les estampilles de transactions, il est 
nécessaire de mémoriser l’estampille de la dernière transaction ayant 
opéré sur un granule. Ceci est effectué au moyen de la notion d’estam- 
pille de granule. 


Valeur numérique associée à un granule mémorisant l'estampille de la dernière transaction 


fé 16 : Estampille de granule (Granule timestamp) 
ayant opéré sur ce granule. 


Afin de mieux caractériser les opérations effectuées, il est possible de dis- 
tinguer une estampille en lecture (mémorisation de l'estampille de la der- 
niére transaction ayant exécuté READ) et une estampille en écriture 
(mémorisation de l'estampille de la derniére transaction ayant exécuté 
WRITE) pour chaque granule. 


La gestion d'estampiles de granules pour contrôler les accès 
concurrents peut s'effectuer par réservation de place mémoire secon- 
daire dans chaque granule. Une telle stratégie présente deux inconvé- 
nients : 

1. la place mémoire utilisée peut être non négligeable, par exemple quel- 
ques octets par page ; 

2. la mise à jour des estampilles de granules, notamment lors des opéra- 
tions de lecture, peut conduire à des entrées-sorties supplémentaires : 
il faut en effet modifier l'estampille du granule sur disque lors d'une 
lecture. 


Ces problèmes peuvent être évités en oubliant les estampilles trop 
vieilles et en gérant une table des estampilles de granules en mémoire 
[Bernstein 80]. En effet, les conflits d'accés ne peuvent survenir qu'entre 
transactions concurrentes. De ce fait, il n'est pas nécessaire de conserver 
les estampilles correspondants à des transactions non simultanées avec 
les transactions en cours. En conséquence, les estampilles peuvent être 
stockées dans des tables en mémoire centrale de tailles limitées. Une 
entrée d'une telle table contient l'identificateur du granule avec l'estam- 
pille du granule correspondante. En addition à la table, une entrée 
contient la valeur m de l'estampille la plus grande qui a été purgée de la 
table. Pour exécuter un des algorithmes de contróle ci-dessous décrits, 
un contrôleur recherche l'identificateur du granule dans la table. S'il Je 
trouve, il trouve également l'estampille associée, sinon la valeur m est 
une borne supérieure de cette estampille. Afin d'assurer la sécurité des 
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contrôles quelle que soit la taille de la table et la stratégie d’élimination 
des estampilles de cette table, la valeur m sera affectée comme estampille 
d'un granule ne figurant pas dans la table. Ainsi, il devient méme possi- 
ble d'éliminer des grariules de la table dès qu'elle est saturée. 


4.3. — Algorithme d'ordonnancement total 


Cet algorithme consiste à vérifier que les accés aux granules par les 
transactions s'effectuent bien dans l'ordre affecté au lancement et repéré 
par les estampilles de transactions. Par suite, si deux transactions T; 
d'estampille i et T; d'estampille j avec i inférieur à j opérent sur un méme 
granule, le contróleur contrólant les accés à ce granule vérifie que T; pré- 
céde T,. Dans le cas contraire, le contróleur provoque simplement la 
reprise d'une des deux transactions. Il est à souligner que cet algorithme 
ne distingue pas les opérations de lecture et écriture, et de ce fait 
séquence les lectures qui sont permutables et donc non conflictuelles. En 
revanche, la gestion d'une estampille unique est suffisante. 


La figure VII.12 décrit l'algorithme d'ordonnancement total. g est 
le granule accédé par la transaction T; d'estampille i. E(g) est l'estampille 
du granule g. ABORT est une procédure provoquant la reprise d'une des 
transactions T; ou T). 


* Procédure READ (T,9) ; 
Si (E(g) < i) alors 
« exécuter la lecture » ; 
E(g) := i; 
Sinon ABORT ; finsi 





fin READ 
* Procédure WRITE (Tg) ; 
Si (E(g) x i) alors 
« exécuter l'écriture » ; 
E9:- i; 
Sinon ABORT; finsi 
fin WRITE 


Fi 


g. VII.12. — Algorithme d'ordonnancement total 
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Selon que l’on provoque la reprise de la transaction demandant 
l'opération (Tj) ou de la transaction ayant effectué l'opération conflic- 
tuelle (Tj), les problèmes de relance de transactions se posent différem- 
ment. Dans le premier cas, T; devra être relancée avec une nouvelle 
estampille i' supérieure à j afin que le conflit ne se produise plus. Mais il 
est possible que T; entre de nouveau en conflit avec une autre transaction 
T;’, et doive encore avorter, ce processus pouvant continuer indéfini- 
ment. Afin d'essayer d'éviter ce probléme de reprise permanente de tran- 
saction, on peut assigner arbitrairement à la transaction une nouvelle 
estampille suffisamment grande ; mais, de toute facon, une autre tran- 
saction avortée peut encore créer des conflits répétés. 


Dans le deuxiéme cas T; peut étre relancée avec la méme estampille. 
En effet, une transaction plus vieille (avec une estampille plus faible) 
devient prioritaire. Il n'y a alors pas de risques de reprise permanente de 
transactions. Cependant deux problèmes difficiles voire insolubles sont 
soulevés par cette méthode. La reprise de T; nécessite (1) la restauration 
de la précédente version ainsi que l'estampille du granule accédé et (2) le 
nouveau contróle de l'ordre des accés en accord avec celui des estampil- 
les de transactions ; si l'ordre n'est pas respecté il faut reprendre la tran- 
saction ayant accédé au granule avant T;. 


4.4. — Algorithme d'ordonnancement partiel 


L'algorithme précédent ordonne toutes les opérations sur les granu- 
les. En fait, il est nécessaire d'ordonner les seules opérations non permu- 
tables, c'est-à-dire READ/WRITE, WRITE/READ et WRITE/WRITE. 
L'algorithme présenté ici consiste à vérifier que les séquences 
READ/WRITE, WRITE/READ et WRITE/WRITE s'effectuent bien 
dans l’ordre affecté au lancement et repéré par les estampilles de transac- 
tions [Bernstein 80]. 


Pour ceci, deux estampilles sont associées aux granules : EL, 
l'estampille en lecture qui est l'estampille de la plus jeune transaction 
(transaction d'estampille la plus élevée) ayant exécuté READ et EE, 
l'estampille en écriture qui est l'estampille de la derniére transaction 
ayant exécuté WRITE. Lorsqu'une transaction exécute READ, le 
contróleur contróle le séquencement correct du READ par rapport au 
dernier WRITE, c'est-à-dire que l'estampille de la transaction lisant doit 
&tre supérieure à l'estampille en écriture EE. Lorsqu'une transaction exé- 
cute WRITE, le contróleur vérifie le séquencement correct du WRITE 
par rapport au READ et au WRITE précédemment exécutés, c'est-à-dire 
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que l'estampille de la transaction écrivant doit être supérieure à l'estam- 
pille en lecture et à l'estampille en écriture du granule. La figure VII.13 
donne une représentation plus précise de l'algorithme d'ordonnance- 
ment partiel. A l'exception des estampilles du granule g, notées EL(g) et 
EE(g) les notations sont les mêmes que celles employées figure VII.12. 
MAX est une fonction choisissant la valeur maximum des paramétres en 


arguments. 


* Procédure 
Si 
Sinon 

fin READ 

* Procédure 


$i 


Sinon 
fin WRITE 


F 


g. 


* Procédure 


Si 


Sinon 


fin WRITE. 


Bases de données 


READ (T,9) ; 

(EE(g) x i) alors 
«exécuter la lecture » ; 
EL(g) : 2 MAX (EL(g), i) ; 


ABORT ; finsi 


WRITE (T;.g) ; 

(EL(g) < i) et (EE(g) < i) alors 
« exécuter l'écriture » ; 
EE(g):= i; 


ABORT ; finsi 


VII.13. = Algorithme d'ordonnancement partiel 


WRITE (T,9) ; 


(EL(g) < i) alors 

Si (EE(g) < i) alors 
« exécuter l'écriture » ; 
EE(g) : = i; 

finsi ; 








ABORT ; finsi ; 


Fig. VII.14. — Algorithme d'ordonnancement partiel 


avec la règle d'écriture de Thomas 
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Il est utile de noter que l'algorithme d'ordonnancement partiel 
conduit à avorter inutilement des transactions voulant écrire un granule. 
En effet, si l’estampille i de la transaction vérifie EE(g) > i < EL(e), il 
suffit d'ignorer son écriture, celle-ci cherchant à placer une information 
dépassée dans la base de donnée. Ceci est connu sous le nom de « Régle 
d'écriture de Thomas » (Thomas 79]. L'algorithme WRITE correspon- 
dant est écrit figure VII.14. 


4.5. — Algorithme d'ordonnancement partiel multi-version 


La stratégie précédente peut étre améliorée en gardant plusieurs ver- 
sions d’un même granule [Reed 79]. Pour chaque granule g, le système 
peut maintenir : 

— un ensemble d'estampilles écriture (EE;(g)) avec les valeurs associées 
(V,(g)), chacune d'elles correspondant à une version i ; 
— un ensemble d'estampille lecture (EL;(g)]. 


Il est alors possible d'assurer l'ordonnancement des lectures par 
rapport aux écritures sans jamais reprendre une transaction lisant. Pour 
cela, il suffit de délivrer à une transaction T; demandant à lire le granule 
g la version ayant une estampille en écriture immédiatement inférieure à 
i. Ainsi, T; précédera toutes les transactions d'estampilles supérieures 
écrivant le granule considéré et suivra celles d'estampilles inférieures. T; 
sera donc correctement séquencée. Tout se passe comme si T; avait 
demandé la lecture juste après l'écriture de la version d'estampille immé- 
diatement inférieure. L'algorithme de contróle de l'opération READ 
avec un dispositif d'ordonnancement partiel multi-versions est repré- 
senté figure VII.15. 


Il est également possible de forcer l'ordonnancement des écritures 
de T, en insérant une nouvelle version créée par T; juste aprés celle 
d'estampille immédiatement inférieure, soit V;(g). Cependant, si lors des 
reséquencements de cette écriture, une transaction T, (k > i) a lu la ver- 
sion V,(g), alors cette lecture devrait être reséquencée. Ceci n'est possible 
que si la transaction T, peut étre reprise. Afin d'éviter la reprise de tran- 
sactions terminées, on préférera reprendre l'écrivain T; avec une nouvelle 
estampille i’ supérieure à k. 


L'algorithme de contróle de l'opération WRITE correspondant est 
représenté figure VII.15. Les notations sont identiques à celles utilisées 
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figures VII.13 et 14, auxquelles sont ajoutés des indices pour les numéros 
de versions. 


* Procédure READ (T;g) ; 


j:= «numéro de la dernière version de g » ; 
Tant que EE(g) > i faire 


j:= j - 1ifin Tant que; 
« exécuter la lecture de g version j » ; 
EL(g) := MAX (EL(g), i) ; 
fin READ; 





* Procédure WRITE (T, g) ; 


j:= «numéro de la dernière version deg»; 
Tant que EE{g) > i faire 
j:=j- 1;fin Tant que; 
Si EL(g) > i alors ABORT ; 
Sinon 








« exécuter l'écriture en insérant une version (| + 1) deg» 
EE. (g):= i; finsi ; 


fin WRITE. 


Fig. VII.15. — Algorithme d'ordonnancement partiel multi-versions 


La figure VII.16 illustre l'algorithme avec les deux possibilités de 
reprise (b et c). Les transactions entrent en conflit sur un granule g uni- 
que dont les versions successives sont représentées par des rectangles. La 
situation originale est représentée figure VII.16 (a). Trois versions du 
granule existent, successivement créées par les transactions 1,5 et 8. La 
version 1 a été lue par la transaction 1, la version 2 par la transaction 7 et 
la version 3 par la transaction 8. Ensuite, nous supposons que T, accom- 
plit une écriture sur le granule g après avoir lu la version 2 créée par T,. 
Dans la figure VIL.16 (b), T, a été annulée, T; a accompli son écriture qui 
crée une nouvelle version et T; a été reprise avec la même estampille 7 et a 
lu la nouvelle version créée. L'autre alternative possible est représentée 
figure VII.16 (c) : T; a été annulée et reprise avec une nouvelle estampille 
10 





| 
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Version 1 Version 2 Version 3 
(a) EE EL EE EL EE EL 


8 8 
Situation 
de départ 


Si Tg veut écrire ce granule, on doit reprendre T; avec la méme estampille 7 (figure (b)) ou 
reprendre Tg avec par exemple l'estampille 10 (figure (c)). 


TEES ES 
semi 


Fig. VII.16. = Illustration de différentes séquences d'opérations 
contrôlées par l'algorithme d'ordonnancement partiel multi-versions 















































5. ALGORITHMES DE VERROUILLAGE DEUX PHASES 


5.1. — Principes de base 


Les stratégies précédentes laissent s'exécuter les transactions en 
contrólant que les accés conflictuels à un méme granule sont exécutés 
dans l'ordre prédéfini au lancement des transactions. Dans le cas oü cet 
ordre n'est pas respecté, on reprend généralement la transaction accé- 
dant. Ces stratégies peuvent donc être qualifiées de détection des exécu- 
tions non sérialisables qui sont alors corrigées par reprise de transac- 
tions. Les stratégies de type verrouillage consistent au contraire à éviter 
la génération d'exécution incorrecte en faisant attendre les transactions 
voulant exécuter des opérations conflictuelles sur un méme objet. 


Le premier objectif des algorithmes de verrouillage est de ne laisser 
s'exécuter simultanément que des opérations compatibles. Pour cela, la 
notion de mode d'opération est introduite. 


Classe caractérisant une opération et permettant de déterminer ses compatibilités avec les 


| Notion 17 : Mode d'opération (Operation mode) 
autres opérations. 
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Les modes d'opérations les plus classiques sont les modes lecture et mise 
à jour. Le mode lecture correspond à toute opération effectuant seule- 
ment des lectures alors que le mode mise à jour correspond à toute opé- 
ration effectuant des écritures, insertions ou modifications. Il permet 
également les lectures. Le groupe de travail DBTG CODASYL a pour sa 
part proposé les modes suivants : 


M1 = consultation non protégée, 

M2 = consultation protégée, 

M3 = mise à jour non protégée, 

M4 = mise à jour protégée, 

M5 = consultation exclusive, 

M6 = mise à jour exclusive. 

De manière générale, il est possible de déterminer les compatibilités 
de modes d'opérations par une matrice C appelée matrice de compatibi- 
lité des opérations ; cette matrice est définie par C = (Cij) où Cij = 1 si 
et seulement si les modes d'opérations Mi et Mj sont compatibles et Cij 
= O sinon. Il est à noter que la matrice C est symétrique puisque la rela- 
tion de compatibilité entre modes est elle-même symétrique. Pour les 
modes m, = lecture et m, = mise à jour, les compatibilités sont définies 
par: 


1 0 
C= 
0 0 


Pour les modes proposés par le DBTG, on a : 


O O = 
ooooaa 
00010 
00000 
000000 
000000 


5.2. — Protocole de verrouillage 


Un contrôleur ne laisse s’exécuter simultanément sur un même gra- 
nule que des opérations de modes compatibles. Pour ce faire, il doit 
connaître le début de chaque opération sur un granule ainsi que les 
modes nécessaires à l'exécution de cette opération. De même, il est 
nécessaire d'indiquer au contróleur contrólant un granule qu'une opéra- 
tion est terminée. Pour cela, un protocole de verrouillage est spécifié. 
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Notion 18 : Protocole de verrouillage (Locking protocol) : 
Protocole d'accès à des granules partagés caractérisé par des demandes d'autorisation 


d'opérations et des signalements de fin d'opérations. 


La plupart des protocoles sont composés de deux actions spéciales du 


type suivant : 

— LOCK (g,M) permet à une transaction d'indiquer au contróleur 
contrólant le granule g le début d'une opération correspondant au(x) 
mode(s) définis par M. 

— UNLOCK (g) permet à une transaction d'indiquer au contróleur 
contrólant le granule g qu'elle a terminé l'opération en cours sur g. 


Le protocole proposé nécessite donc l'exécution de deux actions 
supplémentaires par opérations : LOCK et UNLOCK. L'interface visi- 
ble aux transactions peut étre allégée en intégrant automatiquement la 
demande de verrouillage aux actions permettant de rechercher des gra- 
nules dans la base. Les recommandations du DBTG permettent par 
exemple de verrouiller automatiquement l'article courant associé à une 
transaction et de le déverrouiller dés qu'il n'est plus référencé par un 
repère navigationnel. Deux primitives additionnelles sont également pro- 
posées pour permettre le verrouillage en dehors des articles courants 
(KEEP et FREE). Beaucoup de systèmes groupent les déverrouillages 
soit en fin de transaction, soit en des points intermédiaires oü la base de 
données est cohérente, si bien qu'il n'est pas nécessaire de demander 
individuellement le déverrouillage de chaque granule. Ceci facilite d'ail- 
leurs les reprises en cas de pannes. Quoiqu'il en soit, si l'interface 
LOCK/UNLOCK peut étre cachée aux usagers, il existe au moins logi- 
quement une interface équivalente à l'intérieur du systéme. 


5.3. — Algorithmes de verrouillage 


Afin de ne laisser s'exécuter simultanément sur un méme granule 
que des opérations compatibles, il est nécessaire de mémoriser les modes 
d'opérations en cours d'exécution sur chaque granule. Pour cela, une 
maniére simple consiste à associer, à chaque couple granule g - transac- 
tion Ti opérant sur ce granule, un vecteur de bits [en supposant e modes 
d'opérations possibles] : 





| 
| 
j 
| 
| 
| 
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où a, = 1 si le mode M; est en cours d'exécution pour le compte de la 
transaction Ti sur le granule g et 0 sinon. De manière similaire, nous sup- 
posons que les modes demandés lors de l'exécution d'une action LOCK 
(g,M) sont définis par un vecteur de bits : 


m, 


où m; = 1 si le mode Mj est demandé et 0 sinon. 


Il est alors possible de démontrer le théorème suivant où les opéra- 
teurs suivants sont utilisés : 


V union logique de vecteurs booléens 
7 négation logique de vecteurs booléens 
c inclusion logique de vecteurs booléens 


* produit matriciel booléen (l'élément (i,j) de la matrice produit 
est l'union des intersections des éléments de méme rang de la i* 
ligne de la matrice gauche et de la j* colonne de la matrice 
droite). 


THÉORÈME 3 : 

Les modes d'opérations demandés lors d'une primitive (LOCK (g), M) 
exécutée par une transaction T, sont compatibles avec les modes en cours 
d'exécution sur g par les autres transactions si et seulement si : 


Mc 7( 77* V A&i) 
i#p 


Preuve : 

V A (g,i) est un vecteur de bits dont le bit j est à 1 si et seulement si le 
mode M, est en cours d'exécution sur le granule g par une transaction 
autre que T,. 1 C est le complément de la matrice de compatibilité. Par 
suite, "C * V A (g,i) est un vecteur de bits dont le bit j est à 1 si et 
seulement si le mode M; est incompatible avec un mode en cours d'exécu- 
tion sur le granule g par une transaction autre que T, » Finalement, 
7( 7C * V A (g,i)) est donc un vecteur de bits représentant tous les 
modes d'opérations compatibles avec les modes en cours d'exécution sur 
le granule g par une transaction autre que Tp. Tout vecteur inclus dans 
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ce dernier correspond donc à des modes compatibles avec ceux en cours 
d'exécution sur le granule g par une transaction autre que Tp. 














Un algorithme de verrouillage nécessite la définition d'une stratégie 
dans le cas où les modes d'opérations demandés lors de l'exécution d'une 
primitive LOCK ne sont pas compatibles avec les modes en cours. La 
stratégie la plus simple consiste à rendre un code réponse « granule 
occupé » à la transaction. Afin de contrôler les attentes, il est en général 
préférable de mettre les demandes en attente et de bloquer la transaction 
appelante jusqu'à ce que le granule désiré devienne disponible. Une file 
d'attente Q [g] peut alors étre associée à chaque granule g occupé. Cette 
file contient les demandes de verrouillage (modes et identificateur de 
transaction) en attente dans l'ordre de priorité qui coincide en général 
avec l'ordre d'arrivée. La figure VIL.17 décrit des algorithmes de 
verrouillage/déverrouillage correspondant à une telle stratégie et exécu- 
tés pour la transaction Tp. 


* Procédure LOCK (g,M) ; 
siMc 1(71C*x V A(g,) 
ïiz*p 
alors A (g,p) := A (g,p) VM; 
sinon « Insérer (p,M) dans Q [g] » ; 
« Bloquer la transaction Tp » ; finsi ; 


fin LOCK. 





* procédure UNLOCK (g) ; 
A (g,p) := (0); 
Pour chaque (q,M’) de Q [g] faire 
siM'c 7( 7CG* V A(gi) 


iq 
alors À (g,q) := A (ga) V M'; 
« Extraire (q,M") de Q[g] » ; 
« Débloquer la transaction Tq » 
finsi ; 
fin pour ; 
fin UNLOCK. 





Fig. VII.17. — Algorithmes de verrouillage et déverrouillage 


5.4. — Restriction deux phases 


Les algorithmes de verrouillage présentés ci-dessus permettent l'exé- 
cution simultanée sur un méme granule uniquement d'opérations com- 
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patibles. Mais nous voulons obtenir une exécution des opérations de 
facon à avoir une exécution des transactions sérialisable (qui donne le 
méme résultat qu'une succession des transactions). Pour cela, il a été 
montré qu'il suffisait de restreindre l'utilisation des actions LOCK et 
UNLOCK dans les transactions [Eswaran 76]. Nous introduisons ci- 
dessous cette restriction appelée « restriction deux phases ». 


Tout d'abord, il est nécessaire de souligner que toute transaction 
respectant le protocole de verrouillage défini jusqu'ici doit exécuter 
LOCK avec le mode d'opération correct avant d'exécuter une opération 
sur un granule et doit exécuter UNLOCK plus ou moins longtemps aprés 
la fin d'exécution de cette opération. Dans la suite, nous ne considérons 
que des transactions ainsi bien formées. 


Aprés la remarque précédente, il est possible d'introduire la notion 
de transaction deux phases. 


Notion 19 : Transaction deux-phases (Two phase transaction) 
Transaction qui n'exécute pas de LOCK aprés avoir exécuté UNLOCK. 


Ainsi, une transaction deux-phases doit verrouiller tous les granules sur 
lesquels elle opére avant de commencer à déverrouiller. La courbe d'évo- 
lution typique du nombre de granules verrouillés par une transaction 
deux-phases est représentée figure VII.18. 


Nombre 
de granules 
verrouillés 











| Temps 
1*'e phase de 2* phase de 


verrouillage déverrouillage 
Début Verrouillage Fin 
transaction maximum transaction 


Fig. VII.18. =+ Evolution du nombre de granules verrouillés 
par une transaction deux-phases 


Le théoréme suivant montre l'intérét des transactions deux-phases 
et va nous permettre d'introduire des régles d'utilisation du protocole de 
verrouillage ne laissant se produire que des exécutions sérialisables. 
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THÉORÉME 4: 
Toute exécution compléte d'un ensemble de transaction deux-phases est 
sérialisable. 


Preuve : 

Une exécution sérialisable est une exécution dont le graphe de précé- 
dence ne posséde pas de circuits. Considérons alors une exécution com- 
plète d'un ensemble [T,, T, ... T,] de transactions deux-phases et suppo- 
sons qu'il existe un circuit de précédence T, — Tj ... T, — Ti. 


Il en découle immédiatement que : 


— T, « LOCK » un granule g, aprés que T, « UNLOCK » ce granule 
Bu 5 
— Tj « LOCK » un granule g; aprés que T; « UNLOCK » ce granule 
£a 5 


— T, « LOCK » un granulé g; aprés que Tn « UNLOCK » ce granule 


Chaque transaction Ty, T, ... étant deux-phases, elle exécute 
« UNLOCK » seulement lorsqu'elle a terminé tous ses « LOCK ». De ce 
fait, T; exécute « UNLOCK » sur g; avant d'exécuter « LOCK » sur gi. 
Par suite T; n'est pas deux-phases, ce qui est contraire aux hypothèses. 
D 


Il est maintenant possible d'introduire les régles d'utilisation des 
primitives LOCK/UNLOCK que les transactions doivent respecter dans 
un systéme de bases de données : 


— (RI) Toute transaction doit exécuter LOCK avec le(s) mode(s) 
d'opération correct(s) et le granule choisi avant d'exécuter une opération 
sur ce granule ; 

— (R2) Toute transaction doit exécuter UNLOCK sur le granule choisi 
plus ou moins longtemps aprés l'exécution de l'opération ; 

— (R3) Toute transaction ne peut exécuter LOCK aprés avoir exécuté 
UNLOCK. 


Tout contróleur doit vérifier que les transactions dont il contróle l'exécu- 
tion suivent bien ces règles. Dans le cas particulier courant où seul les 
modes d'opération lecture et écriture sont distingués, la régle R1 se tra- 
duit par le fait qu'une transaction doit demander le verrouillage en lec- 
ture lors de la lecture d'un granule sans intention de modification et en 
écriture lors de la lecture d'un granule avec intention de modification. 
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Finalement le verrouillage deux-phases nécessite que chaque tran- 
saction passe par un état de verrouillage maximum où tous les granules 
accédés sont verrouillés. Il en découle que l'ordre d'accès aux granules 
imposé aux transactions est celui dans lequel les transactions atteignent 
cet état maximum. Le verrouillage deux-phases peut donc étre vu comme 
un ordonnancement des transactions. L'ordre n'est pas affecté a priori 
comme dans les algorithmes basés sur les ordonnancements initiaux, 
mais il est déterminé par le moment où la transaction atteint son état de 
verrouillage maximum. 


5.5, — Problémes de verrou mortel ou interblocage 


Rappelons tout d'abord la définition du verrou mortel (Coffman 
71]. 


Notion 20 : Verrou mortel ou interblocage (Deadlock) 

Le verrou mortel ou interblocage est la situation à laquelle on aboutit lorsque des granules 
ont été verrouillés dans un ordre tel qu'un groupe de transactions vérifie les deux proprié- 
tés suivantes : 

1. chaque transaction du groupe est bloquée en attente d'un granule ; 

2. l'exécution supposée de toutes les transactions n'appartenant pas au groupe ne per- 
met pas de débloquer une des transactions du groupe. - 


Le verrou mortel est un sous-problème soulevé par le verrouillage 
difficile à résoudre. On connaît trois façons de traiter ce problème : la 
prévention, la détection et l'évitement [Howard 73]. L'évitement 
demande, par avance, la connaissance des granules qui seront requis par 
les transactions ; ceci est pratiquement impossible dans un systéme tran- 

"sactionnel. Donc, la prévention et la détection, que nous étudions ci- 
dessous après avoir vu des représentations des verrous mortels par des 
graphes, restent les deux méthodes possibles. 


Présentons tout d'abord un exemple de verrou mortel. Soient T, et 
T; deux transactions. La transaction T, a obtenu le verrouillage d'un gra- 
nule g, en mise à jour et attend le verrouillage d'un granule g, également 
en mise à jour. La transaction T, a obtenu le verrouillage de ce même 
granule g, en mise à jour et attend celui de g, en consultation protégée 
(fig. VII.19). L'impossibilité d'exécuter des mises à jour simultanément 
avec d'autres mises à jour ou des consultations protégées sur un méme 
granule fait que les deux transactions s'attendent entre elles : il y a une 
situation de verrou mortel. 


Nous présentons ci-dessous deux types de graphes représentant les ver- 
rous mortels : le graphe des attentes et le graphe des allocations. 
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T LOCK (g1, mise à jour) T2 
La 


LOCK {g2, mise à jour) 


DEN E 


LOCK (g1, consultation protégée) 


= 


Fig. VII.19. — Exemple d'interblocage ou verrou mortel 


5.5.1. — Graphe des attentes 


Le graphe des attentes [Murphy 68] est un graphe G (T, ) où T est 
l'ensemble des transactions concurrentes {T,, T,, ... T„j se partageant les 
granules G,, G,, ... G, et I est la relation « attend » définie par : T, 
« attend » T, si et seulement si T, attend le verrouillage d'un granule g; 
alors que cette requéte ne peut pas étre acceptée parce que g, a déjà été 
verrouillé par T,. 


Le théorème suivant avait été introduit dès 1968 [Murphy 68] : 


THÉORÈME 5 : 
Il existe une situation de verrou mortel si et seulement si le graphe des 
attentes posséde un circuit. 


Preuve : 
Si le graphe des attentes posséde un circuit, c'est qu'il existe un groupe 
de transactions tel que : 


T; attend T, 
T; attend T, 


T, attend T, 


Chaque transaction du groupe est donc bloquée en attente d'un granule 
du fait de l'utilisation de ce granule par une autre transaction du groupe. 
La fin d'exécution de toutes les transactions n'appartenant pas au 
groupe ne permet donc pas de débloquer une transaction du groupe. 


Réciproquement, l'existence d'une situation d'interblocage implique 
l'existence d'au moins un circuit. S'il n'en était pas ainsi, tout groupe de 
transaction serait tel que le sous-graphe des attentes qu'il engendre ne 
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possèderait pas de circuit. Après exécution de toutes les transactions 
n’appartenant pas au groupe, il serait donc possible de débloquer une 
transaction du groupe puisqu’un graphe sans circuit possède au moins 
un sommet pendant. 














La figure VII.20 illustre le théorème 5 sur l'exemple introduit ci- 
dessus. 


(g2, mise à jour) 


(g1, mise à jour) " © 


ig2, mise à jour) 
(91. consultation protégée) 


Fig. VII.20. — Graphe des attentes avec circuit 


Toutes les transactions appartenant à un circuit sont en situation de ver- 
rou mortel ; de plus, une transaction attendant une transaction en situa- 
tion de verrou mortel est elle-même en situation de verrou mortel (fig. 
VII.21). 


Fig. VII.21. — Transactions en situation de verrou mortel 


Il est intéressant d'établir le rapport entre graphe des attentes et gra- 
phe de précédence. Par définition, si une transaction T; attend une tran- 
saction T;, alors T; a verrouillé un granule g dont le verrouillage est 
demandé par T; dans un mode incompatible. Ainsi l'opération pour 
laquelle T; a verrouillé g sera exécutée avant celle demandée par T car les 
deux opérations sont incompatibles et donc non permutables. Donc T; 
précède T;. Toutefois la relation de précédence n'implique pas générale- 
ment la relation d'attente. Donc, en changeant l'orientation des arcs du 
graphe des attentes, on obtient un sous-graphe du graphe de précédence. 
Ceci implique que si le graphe des attentes a un circuit, il en sera de 
méme pour le graphe de précédence. En conséquence, une situation de 
verrou mortel ne peut pas donner une exécution sérialisable méme s'il 
était possible de terminer les transactions interbloquées. 
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5.5.2. —- Graphe des allocations 


Le graphe des allocations [Holt 72] est lui composé de deux ensem- 
bles de sommets : 


— l’ensemble T des transactions, 
— l’ensemble G des granules. 


Un arc relie le granule G; à la transaction T, si et seulement si T, a 
obtenu le verrouillage de G, dans au moins un mode d'opération ; l'arc 
est valué par les modes d'opérations alloués. Un arc relie la transaction 
T, au granule G, si et seulement si T, a demandé et n'a pas encore obtenu 
l'allocation de ce granule ; l'arc est valué par les modes d'opérations 
demandés. La figure VII.22 représente le graphe des allocations de 
l'exemple de la figure VII.20. 





Ti 9 i" Mise à jour T2 } Transactions 
à R i " ; 
er rd Consultation] Mise à jour 
À N protégée 

Nes A + r 

G1 Á` `> G2 ]eranutes 
Allocation 
rS Attente 


Fig. VII.22. — Exemple de graphe des allocations 


Il est simple de démontrer le théoréme suivant : 


THÉORÈME 6 : 
Une condition nécessaire d'existence de verrou mortel est la présence 
d'un circuit sur le graphe des allocations. Cette condition n'est en géné- 
ral pas suffisante. 


Preuve : 

Montrons que s'il n'existe pas de circuits sur le graphe des allocations, il 
ne peut y avoir d'interblocage. En effet, soit T un groupe quelconque de 
transactions. Du fait que le graphe des allocations est sans circuit, le 
sous-graphe obtenu aprés exécution des transactions n'appartenant pas à 
T est sans circuit. Il posséde donc un sommet pendant. Ce sommet ne 
peut être un granule car un granule non verrouillé ne peut être attendu. 
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Dans tout groupe de transaction T, l’exécution supposée de toutes les 
transactions n'appartenant pas au groupe T conduit donc à débloquer 
une transaction du groupe. Il n’y a donc pas situation de verrou mortel. 
Un exemple simple permet de montrer que la condition n’est pas suffi- 
sante. Soient trois transactions T,, T;, T, se partageant deux granules G, 
et G,, et utilisant les modes d'opérations consultation, mise à jour et 
insertion. Supposons que consultation et consultation, consultation et 
insertion sont compatibles (simultanément exécutable sur un méme 
ensemble) alors que mise à jour et consultation, mise à jour et mise à 
jour, mise à jour et insertion, insertion et insertion ne le sont pas. Le gra- 
phe des allocations représenté figure VII.23 posséde un circuit alors qu'il 
n'y a pas situation d'interblocage comme le prouve le graphe des attentes 
correspondant représenté figure VII.24. 

















Ti T2 Ta 
. Insertion 
NA j 
Mise à jour X N, "ARE c Een 
EN 
`U 
91 92 
Fig. VII.23. — Graphe d'allocation 
Allocation avec circuit sans situation 
—. Attente d'interblocage 


Fig. VII.24. — Graphe des attentes 
correspondant 


Il est à remarquer que la condition est suffisante dans le cas où seul 
les modes de lecture et écriture sont distingués. Ceci permet en général de 
détecter les situations de verrou mortel par détection de circuits dans le 
graphe des allocations dans la plupart des systémes classiques. 
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Nous pouvons noter qu'en général il n'y a pas de rapport direct 
entre graphes de précédence et graphes des allocations. Cependant, si les 
seuls modes existants sont lecture et écriture, la présence d'un circuit 
dans le graphe des allocations est équivalente à l'existence d'une situa- 
tion de verrou mortel et donc à celle d'un circuit dans le graphe des 
attentes. Donc, sous cette condition, la présence d'un circuit dans le gra- 
phe des allocations entraîne celle d'un circuit dans le graphe de précé- 
dence. 


5.5.3. — Prévention des interblocages 


La prévention des interblocages consiste à supprimer l'une des 
conditions qui rend possible les situations de verrou mortel. Deux appro- 
ches classiques sont le préordonnancement des ressources (ici, des granu- 
les) et le préordonnancement des transactions. La premiére parait diffi- 
cile à mettre en ceuvre du fait du grand nombre de granules dans une 
base de données. La deuxiéme a donné deux méthodes connues sous les 
noms DIE-WAIT et WOUND-WAIT [Rosenkrantz 78]. Dans les deux 
méthodes, les estampilles de transactions sont utilisées pour définir un 
préordre des transactions. 


L'approche DIE-WAJIT fonctionne comme suit. Quand une tran- 
saction T, demande à verrouiller un granule qui est déjà verrouillé par 
une transaction T; dans un mode incompatible, T; attend T; seulement si i 
« j (c’est-à-dire une transaction plus vieille attend une plus jeune) et 
meurt sinon (est reprise). Ainsi, une transaction ne peut qu'attendre une 
transaction plus jeune et aucun circuit ne peut apparaitre dans le graphe 
des attentes. Quand une transaction meurt, elle est ensuite reprise avec la 
méme estampille de transaction si bien que tót ou tard, elle deviendra la 
plus vieille transaction active et ne mourra pas. 


L'approche WOUND-WAIT est une approche symétrique mais 
avec préemption. Quant T; demande à verrouiller un granule dans un 
mode incompatible, T; attend T; si i > j (ainsi, une transaction plus 
jeune attend une plus vieille) et T; provoque la reprise (tue) T; sii < j 
(ainsi, une transaction plus vieille tue une plus jeune). En conséquence, 
une transaction peut seulement attendre une transaction plus vieille 
qu'elle et aucun circuit ne peut apparaitre dans le graphe des attentes. 
Cette méthode peut étre améliorée en blessant seulement les transactions 
au lieu de les tuer. Alors, une transaction blessée n'a pas le droit d'atten- 
dre, sinon elle est reprise. Une telle amélioration décroit la fréquence des 
transactions abandonnées et reprises. 
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5.5.4. — Détection des interblocages 


Un algorithme de détection de l'interblocage peut se déduire d'un 
algorithme de détection de circuits appliqué au graphe des attentes ou 
des allocations. Nous utilisons ici une mise en ceuvre de l'algorithme qui 
consiste à tester si un graphe est sans circuit par élimination successive 
des sommets pendants. 


Sur le graphe des attentes, un sommet est pendant si la transaction 
qu'il représente n'attend le verrouillage d'aucun granule. Soit donc N(k) 
le nombre de granules dont la transaction T, attend le verrouillage. Une 
première réduction du graphe peut être obtenue par élimination des som- 
mets pendants, donc tels que N(k) = 0. Le problème est alors de recalcu- 
ler les N(k) après réduction pour pouvoir effectuer la réduction suivante. 
Ceci peut être fait en comptant les demandes qui peuvent être satisfaites 
aprés chaque réduction, et en décrémentant N(k) chaque fois que l'on 
compte une demande de la transaction T,. L'application de la méthode 
nécessite deux précautions : 


— marquer les demandes comptées pour ne pas les compter deux fois ; 
— disposer d'une procédure permettant de tester si une demande peut 
être satisfaite compte tenu de l'état des verrouillages des transactions 
non encore éliminées du graphe des attentes. 


Soit donc SLOCK (g;, Q, k) une procédure booléenne permettant de 
tester si la demande Q de la transaction T,, sur le granule g; peut être 
satisfaite compte tenu de l'état d'allocation des granules aux transactions 
présentes dans le graphe des attentes. Cette procédure répond vrai si la 
demande peut être satisfaite et faux sinon. Le code de cette procédure est 
analogue à celui de l'algorithme LOCK, à ceci prés que l'état de verrouil- 
lage n'est pas modifié et que la transaction verrouillante est précisée en 
argument. La figure VII.25 présente une procédure DETECTER répon- 
dant VRAI si il y a situation de verrou mortel et FAUX sinon. 


Quand une situation d'interblocage est détectée, le probléme qui se 
pose est de choisir une transaction à recycler de facon à briser les circuits 
du graphe des attentes. L'algorithme de détection présenté ci-dessus 
fournit la liste des transactions en situation d'interblocage. Il faut donc 
Choisir une transaction de cette liste. Cependant, tous les choix ne sont 
pas judicieux comme le montre la figure VII.26. Une solution à ce pro- 
bléme peut &tre de recycler la transaction qui bloque le plus grand nom- 
bre d'autres transactions, c'est-à-dire qui correspond au sommet de 
demi-degré intérieur le plus élevé sur le graphe des attentes. 
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Le coût d’une solution de type détection avec reprise peut être 
réduit. En effet, il est possible de déclencher un algorithme de détection 
seulement quand une transaction attend un verrouillage depuis un temps 
important (par exemple, quelques secondes), plutôt qu'à chaque début 
d'attente. 


** BOOLEENNE PROCEDURE DETECTER 
début 
T = (liste des transactions T; telles que N(j) + OJ 
= (liste des granules verrouillés par les transactions e T] ; 

Pour « chaque entrée g; de R » faire 

Pour « chaque demande Q de T, en attente de g, 

et non marquée » faire 
Si | SLOCK (g,Q,k) = VRAI alors 











début 
« Marquer Q » ; 
N(k) = N(k) — 1; 


Si N(k) = O alors 
« sortir T„ de T » ; 
« Ajouter les granules verrouillés par T, 
àlalisteR»; 
fin si; 
fin si ; 
fin pour; 
fin pour ; 
SiT = 0 
alors DETECTER = FAUX ; 
sinon DETECTER = VRAI; 
fin DETECTER. 








Fig. VII.25. — Algorithme de détection 
du verrou mortel 


Fig. VII.26. — Graphe d'attente Oo 


de trois transactions 


Le recyclage de T3 ne résoud pas l'interblocage. 


5.6. — Autres problémes soulevés par le verrouillage 


Un autre probléme soulevé par le verrouillage est le probléme de famine, 
encore appelé blocage permanent. Ce probléme survient dés qu'un 
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groupe de transactions se coalise, en effectuant des opérations compati- 
bles entre elles (par exemple des lectures), contre une transaction indivi- 
duelle qui désire effectuer une opération non compatible avec les précé- 
dentes (par exemple une écriture). La transaction individuelle peut alors 
attendre indéfiniment. Les solutions à ce problème consistent en général 
à mettre en file d'attente les demandes de verrouillage dans leur ordre 
d'arrivée et à n'accepter une requéte de verrouillage que si elle est com- 
patible avec les verrouillages en cours et ceux demandés par les requétes 
plus prioritaires en attente. Il faut noter que les algorithmes de préven- 
tion DIE-WAIT et WOUND-WAIT vus au $ 5.5.3 ne conduisent jamais 
une transaction à l'attente infinie. 


Le probléme des fantómes a également été soulevé [Eswaran 76]. Ce 
probléme survient lorsqu'une entité est introduite dans la base de don- 
nées et ne peut être traitée par une transaction en cours qui devrait logi- 
quement la traiter. Par exemple, soit la base de données de réservation 
de places d'avions, représentée figure VII.27, composée des deux rela- 
tions : PASSAGER (nom, numéro de vol, numéro de siége) et VOL 
(numéro de vol, nombre de passagers). Considérons maintenant les tran- 
sactions suivantes : 


T, (1'* partie) : lister la relation PASSAGER 

T, (2? partie) : lister la relation VOL 

T: insérer dans PASSAGER le tuple (FANTOMAS, 100, 13) et 
incrémenter le nombre de passagers du vol numéro 100. 


De plus, supposons que les transactions s'exécutent dans l'ordre : T, (1re 
partie), T;, T, (2° partie). Ceci est une exécution valide puisque T; accède 
à un granule non verrouillé et qui n'existe méme pas lorsque T, exécute 
sa l't partie. Toutefois le résultat de T, est une liste de 3 noms alors que 
le nombre de passagers est 4. « FANTOMAS » est ici un fantóme. 



































PASSAGERS VOL 
Nom N° de vol | N° de siège N? de vol | Nbre de passagers 
DURANT 100 10 100 4 
MARTIN 100 5 
DURAND 100 3 
FANTOMAS 100 13 Fig. VII.27. — Une illustration 
du probléme de fantóme 
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Ce problème, ainsi que la difficulté de citer les granules à verrouiller 
peut être résolu par la définition de granules logiques (dans l’exemple la 
relation PASSAGER) au moyen de prédicats [Eswaran 76]. Le verrouil- 
lage par prédicat permet également de définir des granules de taille varia- 
ble, ajustés aux besoins des transactions. Malheureusement, il nécessite 
des algorithmes pour déterminer si deux prédicats sont disjoints et ce 
problème ne semble pas avoir de solution efficace et satisfaisante dans le 
cas général, Il faut noter que le probléme des fantômes apparaît non seu- 
lement dans les stratégies de verrouillage mais également dans celles 
d'ordonnancement des transactions. 


Un autre probléme est la nécessité de disposer de granules de tailles 
variables et de pouvoir ainsi verrouiller à plusieurs niveaux, par exemple 
la base de données, le fichier et la page [Gray 78]. Afin de rendre compa- 
tible les différents niveaux, la notion de mode d'intention a été intro- 
duite. Les granules sont organisés en hiérarchie de granules de plus en 
plus petits. Par exemple, un granule peut être une base, un segment, une 
relation ou un tuple. Dans un tel contexte, pour chaque granule, il existe 
deux types de mode d'opération possible : les modes normaux et les 
modes intention qui correspondent à l'intention de verrouillage d'un 
descendant du granule considéré. Le protocole pour verrouiller un gra- 
nule dans un mode donné consiste à verrouiller tous les ancétres du gra- 
nule dans le mode intention correspondant à partir de la racine puis à 
verrouiller le granule lui-même dans le mode désiré. Par exemple, pour 
verrouiller un tuple en écriture, une transaction exécutera LOCK 
(BASE, INT.WRITE) LOCK (SEGMENT, INT.WRITE), LOCK 
(RELATION, INT.WRITE), LOCK (TUPLE, WRITE). Le but des 
modes intentions est d'exclure sur un granule G les opérations qui sont 
incompatibles avec celles en cours sur un plus petit granule inclus dans 
G. Il a été montré que les compatibilités entre les modes d'opérations 
normaux et intentions pouvaient étre définies à partir des p modes ini- 
tiaux par la matrice de compatibilité C' construite comme suit : 


mu 


où les p premiers modes d'opérations sont les modes normaux, les p sui- 
vants sont les modes intentions, E est la matrice pleine de 1. Pour ver- 
rouiller un granule dans le mode j, l'algorithme consiste alors à verrouil- 
ler tous les granules contenant celui-ci (ancêtre) en mode intention p + j 
puis à verrouiller le granule en mode normal. Ainsi, les modes normaux 
permettent de verrouiller un granule, alors que les modes intentions per- 
mettent d'exclure les verrouillages sur un granule incompatibles avec 
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ceux effectués sur un sous-granule (un descendant). Un tel algorithme est 
bien adapté au verrouillage à l'intérieur de hiérarchies. Il peut être appli- 
qué dans un systéme relationnel comme dans un systéme réseau. 


6. AUTRES ALGORITHMES DE CONTRÓLE DE CONCURRENCE 


6.1. — Ordonnancement par certification des lectures avant écriture 


Les méthodes d'ordonnancement proposées ci-dessus sont basées 
sur l'ordre d'arrivée des transactions. Dans la plupart des systémes, les 
transactions effectuent réellement leurs mises à jour dans la base de don- 
nées seulement en fin de transaction (commitment). Il est alors possible 
de considérer une transaction comme composée de deux étapes : 


— une étape de lecture et calcul, 
— une étape d'écriture réelle dans la base (commitment). 


Une méthode simple peut alors étre définie pour empécher la production 
d'exécution non sérialisable [Kung 81]. Cette méthode appelée certifica- 
tion consiste à ordonner les transactions selon le moment où elles termi- 
nent la première étape de lecture et calcul, et à contrôler que les accès 
conflictuels aux granules s'effectuent bien dans l'ordre ainsi obtenu. 


Afin de décrire cet algorithme, nous introduirons une primitive 
CERTIFIER qui est supposée être appelée par un contrôleur en fin 
d'étape de lecture et calcul de chaque transaction. Lors de l'exécution de 
CERTIFIER, une estampille déterminée par une horloge ou un comp- 
teur est associée à la transaction exécutante. De plus, la certification est 
acceptée si et seulement si tous les granules lus par la transaction sont 
toujours dans l'état du moment de la lecture et ne risquent pas d'étre 
changés par des transactions précédemment certifiées. Dans le cas 
contraire, la certification est refusée et la transaction reprise. Les 
contróles sont effectués par association à chaque granule d'une estam- 
pille de valeur égale à celle de l'estampille de la transaction ayant effec- 
tué la derniére écriture. Lors de l'exécution d'une écriture réelle dans la 
base de données, cette écriture n'est enregistrée que si l'estampille du 
granule aprés écriture devient supérieure à l'estampille du granule avant 
écriture (régle de THOMAS). Cette régle assure donc la non prise en 
compte d'écriture périmée alors que la précédente assure que lors de la 
certification, toutes les lectures sont non périmées. 
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Les algorithmes de lecture, écriture et certification sont représentés 
figure VII.28. Pour les algorithmes READ/WRITE, g est le granule 
accédé par la transaction T. E(g) est l'estampille du granule g alors que 
ET (g) est l'estampille du granule g mémorisée lors de la lecture de g par 
T. E(T) est l'estampille associée à la transaction T lors de l'exécution de 
CERTIFIER. 


* Procédure READ (T,g) : 
« exécuter la lecture » ; 
ET (9) := E(9) ; 
fin READ. 


* Procédure CERTIFIER (T) ; 

Pour « chaque granule g lu par T » faire 
si ET(g) # E(g) alors ABORT (T) ; fin si ; 
si « il existe une transaction certifiée 

désirant écrire g » alors ABORT (T) ; fin si ; 
fin pour ; 
E(T) := « horloge » ; 
fin CERTIFIER. 


* Procédure WRITE (T,g) ; 
si E(T) > E(g) alors 
« effectuer l'écriture » ; 
E(g) :z E(T) ; fin si ; 
fin WRITE 





Fig. VII.28. — Algorithme d'ordonnancement par validation 


La validité de l'algorithme proposé peut être montrée. Cet algo- 
rithme permet en effet d’assurer : 
1. que l'enregistrement des écritures est effectué dans l'ordre de certifi- 
cation des transactions ; les précédences WRITE/WRITE respectent 
donc l'ordre de certification des transactions ; 
2. qu'une transaction ne peut lire les écritures d'une autre que si la tran- 
saction écrivant a été certifiée et la transaction lisant ne l'a pas été, ceci 
par définition de CERTIFIER ; les précédences WRITE/READ respec- 
tent donc également l'ordre de certification des transactions ; 
3. qu'une transaction certifiée avec succés ne peut avoir lu une entité 
ensuite écrite par une transaction certifiée avant elle ; les précédences 
READ/WRITE respectent donc également l'ordre de certification des 
transactions. 
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Finalement, toutes les opérations non permutables sont donc exécutées 
sur une méme entité dans l'ordre de certification des transactions. Ceci 
assure l'absence de circuits dans le graphe de précédence et la correction 
de l'algorithme. 


6.2. — Ordonnancement au commitment de transaction 


Nous avons récemment proposé une nouvelle méthode basée sur un 
ordonnancement final des transactions [Viemont 82]. Comme nous le 
verrons dans le chapitre suivant, dans les systémes actuels la fin de tran- 
saction est marquée par une action atomique (commit) qui provoque les 
écritures réelles dans la base. Il est possible alors de considérer deux 
estampilles de transactions : l'estampille initiale (heure de lancement) et 
l'estampille finale (heure de commitment). A partir de là, les conflits 
peuvent être résolus selon les principes suivants : 


1. conflit écriture-écriture (WRITE-WRITE) par ordonnancement des 
écritures réelles au commitment à l'aide de la régle de THOMAS ; 

2. conflit lecture-écriture (READ-WRITE) par reprise du lecteur ; 

3. conflit écriture-lecture (WRITE-READ) par attente du lecteur 
jusqu'au commitment de l'écrivain. 


Cet algorithme paraît prometteur car il intègre la notion de commitment 
au contróle de concurrence et permet d'obtenir un degré de parallélisme 
similaire à l'estampillage multi-versions. 


6.3. — Détection de circuits dans le graphe de précédence 


Plusieurs algorithmes de contróle de concurrence permettant un 
degré de parallélisme important peuvent être obtenus en gérant le graphe 
de précédence des transactions et en empéchant, soit par retard d'opéra- 
tions, soit par reprise de transactions, la formation de circuits sur ce gra- 
phe. Cependant le coüt de tels algorithmes nécessitant la détection de cir- 
cuits sur le graphe de précédence est en général prohibitif. 


La raison essentielle à ce coüt élevé est la taille du graphe car une 
transaction ne peut pas en étre retirée aussitót aprés la fin de sa terminai- 
son. En effet, certains circuits ne pourraient plus être détectés. Par 
exemple, si T; précède T; et si T; est active alors que T, est terminée il est 
possible que, lors de l'exécution ultérieure de T;, on ait T; précède T;. Si 
l'arc T,— T; était retiré du graphe, le circuit T; — T; — T; ne serait plus 
visible. 
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7. CONCLUSION 


Deux classes apparaissent dans les méthodes considérées de coritróle 
de concurrence : 


1. ordonnancement par estampillage, 
2. verrouillage. 


Dans le premier cas, les transactions sont ordonnées par rapport à leur 
heure de lancement ou bien de fin. Dans le second cas, l'ordre est donné 
par le point de verrouillage maximum, juste au début de la phase de ver- 
rouillage ; l'ordre est cette fois imposé par le systéme et l'usager ne peut 
pas l'influencer. 


Il faut rappeler que les nécessités de performances ont motivé beau- 
coup de travaux récents sur le contróle de concurrence. Malheureuse- 
ment, peu d'informations approfondies sont disponibles. Nous pouvons 
considérer ce point en tenant compte du degré de parallélisme et des 
besoins en temps et espace mémoire. Du point de vue parallélisme, les 
algorithmes discutés paraissent semblables. Les coüts en temps compren- 
nent essentiellement des temps d'unité centrale trés faibles. La méthode 
des estampillages nécessite la gestion de tables d'estampilles tandis que 
celle des verrouillages requiert celle de tables de verrous. Aussi ces deux 
méthodes semblent équivalentes. A l'heure actuelle, il est difficile de 
donner une préférence à l'une ou l'autre des méthodes en ce qui 
concerne les performances. Il apparait clairement que beaucoup reste à 
faire tant sur le plan de l'analyse que de l'expérimentation. 


En résumé, nous pensons que les principes de base du contróle de 
concurrence sont relativement bien compris. D'autres algorithmes peu- 
vent étre facilement construits, en faisant varier l'instant à laquelle 
l’ordre est défini, en retardant certains types d'actions ou en combinant 
ces différentes méthodes [Bernstein 81]. Ce qui nous manque le plus à 
l'heure actuelle est une évaluation de performances digne de confiance 
basée sur des analyses théoriques détaillées et sur des expérimentations 
extensives. Soulignons également que la plupart des algorithmes de 
contróle de concurrence présentés ici ont souvent été décrits dans un 
contexte réparti, Une telle répartition ne change pas les principes : elle 
introduit seulement de nouveaux problémes tels que la génération d'un 
temps global et la distribution du contróle. 
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Vill. RÉSISTANCE AUX PANNES 
ET SÉCURITÉ DES DONNÉES 


1. INTRODUCTION 


Dans ce chapitre, nous allons aborder les problèmes posés par la 
protection des données contre les pannes et les mauvaises utilisations. En 
particulier, nous développerons les problémes et solutions au maintien 
de l'intégrité des données en face des pannes machines. Le probléme est 
de restaurer, aprés une panne, une base de données cohérente, tout en 
demandant aux usagers de réexécuter un minimum de programmes 
d'application. La bonne résolution de ce probléme est déterminante 
pour l'utilisation des SGBD. Nous introduirons également les problémes 
et solutions proposées afin de contróler les autorisations d'accés aux 
données et de maintenir une certaine confidentialité des données. 
D'autres aspects de l'intégrité des données ne sont guére abordés : les 
contróles d'intégrité, la sécurité des bases de données statistiques, le 
cryptage des données par exemple. Le lecteur pourra consulter [Fernan- 
dez 80], [Denning 79a], [Hoffman 77] pour des synthèses de ces sujets et 
des références plus nombreuses. 


Ce chapitre comporte quatre paragraphes principaux. Les paragra- 
phes 2, 3 et 4 traitent les problémes posés par les pannes : notions de 
base, validation et annulations de transactions, procédures de reprise. Le 
paragraphe 5 présente les techniques essentielles permettant d'assurer la 
sécurité des données. 
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2. LES PRINCIPES DE LA RÉSISTANCE AUX PANNES 


2.1. — Les types de pannes 


Un modéle simplifié de SGBD se compose de transactions, d'un 
systéme et de mémoires secondaires. Les transactions accédent aux don- 
nées au moyen d'actions spécifiques (read, write, etc.). Ces actions sont 
exécutées par le systéme et conduisent à des entrées-sorties sur les 
mémoires secondaires. 


Les pannes peuvent être causées par une erreur humaine, une erreur 
de programmation ou le malfonctionnement d'un composant matériel. 
Il est possible de distinguer plusieurs types de pannes [Gray 78, Fernan- 
dez 80] : 


— La panne d'une action survient quand une commande au SGBD 
est mal exécutée. En général, une telle panne est détectée par le systéme 
qui retourne un code erreur au programme d'application. Celui-ci peut 
alors tenter de corriger l'erreur et continuer Ja transaction. 


— La panne d'une transaction survient quand une transaction ne 
peut continuer par suite d'une erreur de programmation, d'un verrou 
mortel ou d'un mauvais ordonnancement des accés concurrents, d'une 
panne d'action non corrigeable. Il faut alors défaire les mises à jour 
effectuées par la transaction. 


— La panne du système nécessite l'arrét du système et son redémar- 
rage. La mémoire secondaire n'est pas affectée par ce type de panne ; 
par contre, la mémoire centrale est perdue par suite du rechargement du 
systéme. 


— La panne de mémoire secondaire peut survenir soit suite à une 
défaillance matérielle, soit suite à une défaillance logicielle impliquant de 
mauvaises écritures. Dans ces cas, une partie de la mémoire secondaire 
est perdue. Il s'agit là du type de panne le plus catastrophique. 


Les différents types de panne sont de fréquence trés différente. Par 
exemple [Gray 81], les deux premiers types peuvent survenir plusieurs 
fois par minute alors qu'une panne système apparaît en général plusieurs 
fois par mois et qu'une panne mémoire secondaire n'arrive que quelque- 
fois par an. Aussi, seul le dernier type de panne conduit à faire appel aux 
archives et peut étre, dans certains cas trés rares, non récupérable. 
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2.2. — Les objectifs de la résistance aux pannes 


L'objectif essentiel est de minimiser le travail perdu tout en assurant 
un retour à des données cohérentes aprés pannes. Compte, tenu de 
l'aspect non instantané de l'apparition et de la détection des pannes, il 
est considéré généralement que la transaction est /'unité de traitement 
atomique, ou si l'on préfére l'unité de reprise [Gray 80]. Cependant, ceci 
n'est pas toujours vrai et une unité plus faible peut étre retenue, comme 
dans systéme R à l'aide de la notion de point de reprise de transaction 
(savepoint) [Gray 81]. Par exemple, dans le cas que nous considérons où 
la transaction est l'unité de reprise, si une transaction exécute un trans- 
fert de x francs depuis un compte A sur un compte B, soit les deux 
actions < A — A - x ; B — B + x > doivent être exécutées ou aucune 
ne doit l'étre à la fin de la procédure de reprise aprés panne. 


Ainsi, il apparait que les objectifs premiers de la résistance aux pan- 
nes sont de fournir un protocole aux applications permettant de faire, 
défaire et refaire une transaction (do, undo, redo protocole, d’après 
[Gray 81]). Ce protocole se compose donc de trois actions atomiques 
[Lomet 77], c'est-à-dire qui doivent étre soit totalement et correctement 
exécutées, soit pas du tout. Ces trois actions correspondent aux trois 
notions de validation (encore appelée commitment, consolidation ou 
confirmation), d'annulation (encore appelée abort ou abandon) et de 
reprise (encore appelée restauration ou réexécution). Nous définissons 
ci-dessous ces trois notions. 


Notion 1 : Validation de transaction (Transaction Commitment) 

Exécution d'une action atomique spéciale (appelée COMMETTRE), généralement en fin de 
transaction, provoquant l'intégration définitive de toutes les mises à jour de la transaction 
exécutante dans la base de données. 


Notion 2 : Annulation de transaction (Transaction Abort) 

Exécution d'une action atomique spéciale (appelée ANNULER), généralement après une 
panne, provoquant l'annulation de toutes les mises à jour de la base effectuées par la tran- 
saction. 


A noter que l'annulation d'une transaction non validée est en général 


beaucoup plus simple que celle d'une transaction validée. 


Notion 3 : Reprise de transaction (Transaction Recovery) 
Exécution d'une action spéciale (appelée REPRENDRE) qui refait les mises à jour d'une 
transaction précédemment annulée dans la base de données. 
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2.3. — Eléments utilisés pour la résistance aux pannes 


2.3.1. — Mémoire sûre 


Avant tout, il est nécessaire de disposer d’un mécanisme permettant 
de rendre sûres les actions d’écriture sur mémoire secondaire. Plus préci- 
sément, la notion de mémoire sûre permet de rendre atomique l’action 
d'écriture physique : un enregistrement ou page est soit correctement 
écrit sur mémoire secondaire, soit pas du tout ; il ne peut être douteux ou 
partiellement écrit. 


Mémoire découpée en pages dans laquelle une écriture de page est soit correctement exé- 


| Notion 4 : Mémoire Süre (Stable Memory) 


cutée, soit non exécutée. 


La réalisation d'une mémoire süre n'est pas triviale. Les techniques 
utilisées sont en général les codes de redondances, ainsi que les doubles 
écritures. Dans la suite nous considérons les mémoires comme sûres. 


2.3.2. — Journaux 


La méthode la plus classique pour permettre l'annulation et la 
reprise de transaction consiste à utiliser des journaux [Verhofstad 78]. 
On distingue classiquement le journal des images avant et le journal des 
images après, bien que les deux puissent être confondus dans un même 
journal. 


Notion 5 : Journal des Images Avant (Before Image Log) 


Fichier système contenant d’une part les valeurs (images) avant mocifications des pages modi- 
fiées, dans l'ordre des modifications avec les identifiants des transactions modifiantes, et d'au- 


tre part des enregistrements indiquant les débuts, validation et annulation de transactions. 


Notion 6 : Journal des Images Après (After Image Log) 


Fichier système contenant d'une part les valeurs (images) après modifications des pages modi- 
fiées, dans l'ordre des modifications avec les identifiants des transactions modifiantes, et d'au- 


tre part des enregistrements indiquant les débuts, validation et annulation de transactions. 


Afin d'illustrer ceci, la figure VIII.1 représente un enregistrement 
d'un journal contenant à la fois les images avant et aprés. 


Un tel journal peut étre enregistré sur bandes magnétiques ou sur un 
disque séparé. La valeur aprés modification peut contenir simplement les 
différences par rapport à la valeur avant. Les modifications d'une méme 
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transaction peuvent être regroupées dans le journal afin de permettre 
facilement d’isoler les mises à jour d’une transaction. 











IDT Identifiant de transaction 
HMO Heure de la modification 
FMO Fichier modifié 

ADP Adresse de la page modifiée 
IMA Valeur avant modification 
IMP Valeur après modification 











Fig. VIIL1. — Exemple d'enregistrement dans un journal 


Dans la plupart des systémes, les modifications sont tout d'abord 
exécutées dans des tampons en mémoire. Ces tampons sont volatils, 
c’est-à-dire perdus lors d'une panne. Ce n'est bien souvent que lors de la 
validation que les mises à jour sont enregistrées dans le journal et dans la 
base. Afin d'étre capable d'annuler une transaction dans tous les cas, il 
faut écrire les enregistrements dans le journal avant d'écrire les tampons 
dans la base, comme illustré figure VIII.2. 





TAMPONS 





JOURNAL 





Fig. VII.2. — Ordre d'enregistrement 
des mises à jour 





BASE 
DE DONNÉES 


2.3.3. — Sauvegarde 


En cas de perte de la mémoire secondaire, il faut pouvoir retrouver 
une archive de la partie de base détruite. Pour cela, des sauvegardes doi- 
vent étre effectuées périodiquement, par exemple sur bande magnétique. 
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Copie cohérente d'une base locale effectuée périodiquement alors que cette base est dans 


| Notion 7 : Sauvegarde (Backup copy) 
un état cohérent. 


Une sauvegarde peut par exemple être effectuée en début de chaque 
semaine, de chaque journée, de chaque heure... En général, une sauve- 
garde est exécutée quand aucune transaction n'est active. Un problème 
peut être d'exécuter la sauvegarde pendant le fonctionnement normal du 
système. Pour cela un mécanisme de verrouillage spécifique, ou mieux, 
un mécanisme de multi-versions [Reed 79] peut être utilisé. 


2.3.4. = Point de reprise système 


Après un arrêt normal ou anormal du système, il est nécessaire de 
repartir à l'aide d'un état machine correct. Pour cela, on utilise en géné- 
ral des points de reprise système. 


Etat d'avancement du système sauvegardé sur mémoires secondaires à partir duquel il est 
possible de repartir après un arrêt. 


[ec 8 : Point de reprise système (System checkpoint) 

Les informations sauvegardées sur disques comportent en général 
l’image de la mémoire, l’état des travaux en cours, les pointeurs courants 
sur des fichiers séquentiels et en particulier les journaux. Un enregistre- 
ment « point de reprise système » est écrit dans le journal. Lors d’une 
reprise, on repart en général du dernier point de reprise système. Plus ce 
point de reprise est récent, moins le redémarrage est coûteux comme 
nous le verrons ci-dessous. La fréquence optimum des points de reprise a 
été étudiée dans [Gelenbe 79]. 


3. VALIDATION ET ANNULATION DE TRANSACTIONS 


Comme indiqué ci-dessus, la validation de transaction doit permet- 
tre d’intégrer toutes les mises à jour d’une transaction dans une base de 
données de manière atomique, c'est-à-dire que toutes les mises à jour 
doivent étre intégrées ou aucune ne doit l'étre. L'atomicité de la valida- 
tion de transaction rend les procédures d'annulation de transactions non 
validées simples. Le probléme est donc de réaliser cette atomicité. Plu- 
sieurs techniques ont été introduites dans les systèmes afin de réaliser une 
validation atomique. Les techniques peuvent être combinées afin d'amé- 
liorer la fiabilité [Gray 81]. Nous les passons en revue ci-aprés. 
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Tout d’abord, l’atomicité de la validation d’une transaction peut 
être réalisée par la technique des pages d'ombre [Lorie 77]. Avec une 
telle technique, les écritures des transactions ne sont pas exécutées en 
place dans la base mais dans des pages nouvelles séparées propres à la 
transaction, encore appelées pages différentielles [Severance 76]. Avant 
toute lecture, il faut alors que le SGBD consulte les pages différentielles 
validées et non encore physiquement intégrées à la base. Ceci conduit de 
toute manière à alourdir les procédures de consultation et accroître les 
temps de réponse. 


Une solution plus efficace a été proposée dans [Lampson 76]. Cette 
solution, représentée figure VIIL.3, consiste à réaliser une intégration 
physique atomique par basculement des tables des pages. Pour cela cha- 
que fichier de la base de données possède un descripteur pointant sur la 
table des pages du fichier. Quand une transaction désire modifier un 
fichier, une copie de la table des pages est effectuée et les adresses des 
pages modifiées sont positionnées à leurs nouvelles valeurs, de sorte que 
la copie de la table des pages pointe sur la nouvelle version du fichier 
(anciennes pages non modifiées et nouvelles pages modifiées). La valida- 
tion consiste alors simplement à mettre à jour le descripteur du fichier en 
changeant l’adresse de la table des pages. 





Ancienne table des pages 











NOM | Y 
fichier CMM Y 
Ld. mm | | 
No r=" 0.7 ò| k À À 
Anciennes pages 
7 J Â... (ombres) 





Descripteur 
de fichier 








titt 




















Ld =d 
Nouvelles pages 


Nouvelle table des pages 


Fig. VIII.3. — Validation par basculement de la table des pages 
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L'atomicité de la validation d'une transaction peut aussi être réali- 
sée par écriture d'un enregistrement dans le journal [Verhofstad 78]. 
Dans ce cas, les mises à jour d'une transaction sont écrites dans le jour- 
nal puis mises en place dans la base de données. Cependant, elles restent 
invisibles aux autres transactions tant qu'elles ne sont pas validées ; ceci 
est réalisé en verrouillant les pages au fur et à mesure des écritures. La 
validation proprement dite consiste à écrire dans le journal un enregistre- 
ment « transaction validée ». Ensuite, les mises à jour sont rendues visi- 
bles aux autres transactions. 


Dans tous les cas, la validation d'une transaction ayant mis à jour la 
base de données génére un nouvel état, ainsi que des enregistrements 
dans le journal (images des pages modifiées et enregistrement transaction 
validée), comme indiqué figure VIII.4. L'annulation d'une transaction 
ayant mis en place des mises à jour dans la base est une procédure diffi- 
cile. Elle s'effectue à partir du journal des images avant (fig. VIII.4). 
L'annulation nécessite le parcours du journal à l'envers, c'est-à-dire en 
reculant dans le temps. Annuler une transaction validée nécessite 
d'annuler toutes les transactions ayant lu des données écrites par cette 
transaction. Ceci est connu sous le nom d'effet domino [Menasce 78]. 


ANCIEN 
ETAT 










NOUVEL 





ENREGISTREMENTS 
DANS LE JOURNAL 


ANCIEN 


NOUVEL | 
ETAT 

ENREGISTREMENT 

DANS LE JOURNAL 


Fig. VIIL.4. — Principes de la validation et l'annulation avec journal (d'après [Gray 81]). 


Dans la plupart des systémes, un ensemble de processus collabore à 
la vie d'une transaction. Afin de coordonner la décision de valider une 
transaction, un protocole de validation en deux étapes est généralement 
utilisé. Un tel protocole a été proposé dans un contexte de systéme 
réparti [Lampson 76, Gray 78] mais peut étre utile dans un contexte cen- 
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tralisé. La validation en deux étapes peut être vue comme une méthode 
de gestion des journaux : lors de la première étape, les images avant et 
après sont enregistrées dans le journal si bien qu’il devient ensuite possi- 
ble de valider ou annuler la transaction quoiqu'il advienne (exceptée une 
perte du journal) ; cette étape est appelée préparation à la validation ; la 
deuxiéme étape est la réalisation de la validation ou de l'annulation ato- 
mique, selon que la premiére étape s'est bien ou mal passée. La descrip- 
tion d'un tel protocole déborde le cadre de cet ouvrage et pourra étre 
trouvée dans [Baer 81]. 


4. LES PROCÉDURES DE REPRISE 


On appelle procédure de reprise la procédure exécutée lors du redé- 
marrage du systéme aprés un arrét ou une panne. Plusieurs types de 
reprise sont distingués et un schéma de principe possible pour chaque 
type est étudié ci-dessous. Ces procédures consistent à repartir à partir 
du journal et éventuellement de sauvegardes, pour reconstituer une base 
cohérente en perdant le minimum du travail exécuté avant l'arrét. Afin 
de préciser les idées, nous définissons la notion de procédure de reprise. 


Notion 9 : Procédure de reprise (Recovery procedure) 

Procédure systéme exécutée lors du redémarrage du systéme ayant pour objectif de 
reconstruire une base cohérente aussi proche que possible de l'état atteint lors de la 
panne ou de l'arrêt. 


4.1. — La reprise normale 


La reprise normale a lieu aprés un arrét normal de la machine. Lors 
de cet arrét, un point de reprise systéme est écrit comme dernier enregis- 
trement du journal. La reprise normale consiste simplement à restaurer 
le contexte d'exécution sauvegardé lors de ce point de reprise. Une telle 
procédure est exécutée lorsque le dernier enregistrement du journal est 
un point de reprise systéme. 


4.2. — La reprise aprés une panne du systéme 


Ce type de reprise est souvent appelé reprise à chaud [Jouve 77]. 
Rappelons qu'une panne système entraîne la perte de la mémoire cen- 





| 
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trale sans perte de données sur mémoires secondaires. Dans ce cas, le 
système doit rechercher dans le journal le dernier point de reprise 
système et restaurer létat machine associé. Le journal est alors traité en 
avant à partir du point de reprise afin de déterminer les transactions vali- 
dées et celles non encore validées (appelées respectivement gagnantes et 
perdantes dans [Gray 81]). Puis le journal est traité en sens inverse afin 
de défaire les mises à jour des transactions non validées (les perdantes). 
Une telle procédure est illustrée figure VIII.5. Elle est exécutée lors des 
redémarrages du système quand le dernier enregistrement du journal 
n’est pas un point de reprise et que l’opérateur ne signale pas une perte 
de mémoire secondaire. 


Journal 


Début transaction i 
MA li} 

Z Début transaction i + 1 
| M1 i+1 





[Z 

zÀ Dernier point de reprise système 
í Début transaction i + 2 

M1 (i+2 
M2 (i) 








ZA Validation transaction i 
| O M241 
Début transaction i +3 
M1 (i+3 
M2 (i+3 
M2 (i4 2) 

Validation transaction i+ 2 


| wa3den 





— 





= 











Fig. VIII.5. — Exemple de reprise à chaud 


Les transactions i et (i + 2) sont gagnantes alors que (i + 1) et (i+ 3) sont perdantes, 
Mi(i) désigne la j^ mise à jour de la transaction i. 
Les mises à jour défaites sont marquées |. 


4.3. — La reprise après une panne de mémoire secondaire 


Ce type de reprise est souvent appelé reprise à froid. Une telle 
reprise est exécutée lorsqu'une partie des données est perdue, ou lorsque 
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la base est devenue incohérente. Dans ce cas, une sauvegarde cohérente 
de la base ainsi que le journal des activités qui ont suivi sont utilisés afin 
de reconstruire la base actuelle. Il suffit pour cela d'appliquer les images 
après à partir de la sauvegarde et du point de reprise associé. Lorsque le 
journal a été parcouru en avant jusqu'à la fin, la reprise à froid enchaîne 
en général sur une reprise à chaud. 


4.4. — La reprise aprés une panne catastrophique 


Une panne catastrophique survient quand tout ou partie du journal 
sur mémoire secondaire est perdu. Certains systémes, tel systéme R, per- 
mettent de gérer deux copies du journal sur des mémoires secondaires 
indépendantes afin de rendre trés peu probable un tel type de panne. 
Dans le cas où cependant une telle panne survient, il n'existe guère 
d'autre solution que d'écrire des transactions spéciales chargées de tester 
la cohérence de la base en dialoguant avec les administrateurs et de com- 
penser les effets des mises à jour malheureuses. 


5. LA SÉCURITÉ DES DONNÉES 


5.1. — Identification et Autorisation 


Un systéme de bases de données doit assurer la sécurité des données 
qu’il gère, c'est-à-dire que les opérations non autorisées ou mal inten- 
tionnées doivent être rejetées, Pour accomplir une telle opération, il faut 
un sujet qui effectue l'opération et un objet qui la subit [Hoffman 77]. 
Dans les systémes de base de données, les sujets sont les utilisateurs 
devant les terminaux et les objets les données. Les sujets doivent tout 
d'abord étre identifiés. 


Procédé consistant à associer à un sujet un nom ou un numéro qui le désigne de manière 


Le 10 : Identification (Identification) 
unique. 


Un premier moyen de violer la sécurité des données est pour un sujet 
de se faire passer pour un autre. Afin d’éviter cela, on introduit un pro- 
cédé d’authentification des sujets. 


Notion 11 : Authentification (Authentification) 
Procédé permettant de vérifier qu'un sujet est bien qui il prétend être. 


i 
i 
| 
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Le procédé d'authentification le plus courant est l’utilisation de mots de 
passe. Un mot de passe est une chaine de caractéres en principe connue 
du sujet et de l'objet seuls, que le sujet doit fournir pour étre authentifié. 
D'autres procédés plus sophistiqués et plus sürs sont l'utilisation de bad- 
ges, de questionnaires, l'exécution d'algorithmes connus seulement par 
l'objet et le sujet, l’utilisation d'empreintes digitales ou des empreintes 
de la rétine... 


Un sujet authentifié peut alors exécuter certaines opérations sur cer- 
tains objets selon les droits d'exécution accordés par les administrateurs 
du systéme ou plus généralement par d'autres sujets. 


Notion 12 : Autorisation (Authorization) 
Droit d'exécution d'une opération par un sujet sur un objet. 


L'attribution d'une autorisation peut dépendre : 

— du sujet, par exemple de ses priviléges d'accés ou du terminal qu'il 
utilise, 

— de l'objet, par exemple de son nom, son état actuel, son contenu ou 
sa valeur, 

— de l'opération effectuée, par exemple lecture ou écriture, 

— d'autres choses telle l'heure du jour... 


5.2. — Le contróle des autorisations 


Il existe plusieurs maniéres de contróler les autorisations. Une pre- 
miére est l'utilisation de matrices d'autorisations. Une matrice d'autori- 
sations est une matrice dont les lignes correspondent aux sujets et les 
colonnes aux objets, définissant pour chaque couple « sujet-objet » les 
opérations autorisées. 


Considérons par exemple deux relations décrivant les objets NOM 
et RÉSULTAT d'étudiants, et des sujets étudiants, secrétaires et profes- 
seurs. Les opérations que peuvent accomplir les sujets sur les objets nom 
et résultat sont lecture et écriture. Les autorisations peuvent étre codées 
par deux bits, droit d'écriture puis droit de lecture. La figure VIII.6 
représente la matrice correspondant à cet exemple, O signifiant accès 
interdit et 1 accés autorisé. 


En pratique, la matrice d'autorisation peut étre stockée : 


— par ligne : à chaque sujet est alors associée la liste des objets auxquels 
il peut accéder ainsi que les droits d'accés qu'il posséde ; 
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— par colonne : à chaque objet est alors associée la liste des sujets pou- 
vant l'accéder avec les droits d'accès associés ; 

— par élément : à chaque couple « sujet-objet » sont associés les droits 
d'accés du sujet sur l'objet. Dans les systèmes relationnels, la matrice est 
souvent stockée par élément sous forme d'une relation à trois attributs 
sujet-objet-droits. 


NOM RÉSULTAT 
ÉTUDIANT 01 01 
SECRÉTAIRE 11 01 
PROFESSEUR 11 11 


Fig. VIIL6. — Exemple de matrice d'autorisation 


Un moyen plus simple de contrôler les autorisations consiste à asso- 
cier un niveau d'autorisation aux sujets et aux objets. Un niveau d’auto- 
risation est un nombre associé à chaque objet ou à chaque sujet. Un 
accès est autorisé si et seulement: si le niveau du sujet accédant est supé- 
rieur ou égal au niveau de l'objet accédé. Considérons par exemple les 
sujets et objets introduits ci-dessus avec les niveaux d'autorisation : Etu- 
diant (1), Secrétaire (2), Professeur (3), Nom (1), Résultat (3). 


La matrice d'autorisation équivalente est représentée figure VIII.7 : 


NOM RÉSULTAT 
ÉTUDIANT 11 01 
SECRÉTAIRE 11 00 
PROFESSEUR 11 11 


Fig. VIII.7. — Matrice d'autorisation équivalente aux niveaux 


L'inconvénient de la solution niveau d'autorisation est que l'on 
perd la notion d'opération. Cependant, cette solution est simple à 
implanter et de plus elle permet de combiner les niveaux. En effet, si un 
sujet de niveau s, accède au travers d'un équipement de niveau sz, on 
associera au sujet le niveau s = min (s1, $2). Par exemple, s'il existe un 
terminal en libre accés de niveau 1 et un terminal situé dans un bureau 
privé de niveau 3, un enseignant ne conservera ses priviléges que s'il tra- 
vaille à partir du terminal situé dans le bureau. 
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De plus, la méthode peut être étendue, avec des classes de niveaux 
partiellement ordonnées, vers un modèle plus complet de flots d’infor- 
mations [Denning 76]. 


5.3, — La définition des objets 


Le choix des objets à protéger est un des problèmes importants lors 
de la conception d’un module de protection pour un SGBD. Les systè- 
mes anciens tels CODASYL et IMS restreignent les objets protégeables 
aux types d’objets : CODASYL permet de protéger par des clés 
n’importe quel niveau de type d'objet décrit dans le schéma (donnée élé- 
mentaire, article, fichier...) alors que IMS permet de protéger des sous- 
ensembles de champs d'un segment. Au contraire, les systémes relation- 
nels tels Systéme R et INGRES permettent de protéger des ensembles 
d'occurrences de tuples définis par des prédicats, donc dépendants du 
contenu 


Les vues jouent un rôle essentiel dans la définition des objets à pro- 
téger [Chamberlin 75]. Tout d'abord, lorsqu'une vue est considérée 
comme un objet, un usager ne peut accéder qu'aux données décrites dans 
la (ou les) vue à laquelle il a droit. Ensuite, il est possible avec la notion 
de vue de se limiter à la définition d'objets de type relation. Un droit 
d'accés est alors attribué à un usager sur une relation qui peut étre vrai- 
ment implantée comme un fichier sur disque (relation du schéma princi- 
pal), mais qui peut aussi être une relation virtuelle dans une vue résultant 
de l'évaluation d'une question. La technique de modification de ques- 
tions [Stonebraker 76] permet alors de protéger efficacement les tuples 
ou attributs de tuples composant la relation de la vue. 


Une autre approche est d'utiliser le méme langage pour définir les 
objets sur lesquels on autorise des opérations que celui pour exprimer les 
questions. Cette approche est celle de QBE où les questions et les autori- 
sations sont exprimées de la même manière. 


5.4. — La définition des sujets 


La définition des sujets ne pose a priori pas de probléme : tout utilisa- 
teur est un sujet. Cependant, il est utile de considérer des groupes d'utili- 
sateurs. La notion de groupe peut étre étendue de maniére hiérarchique. 
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Dans ce cas, un groupe hérite de toutes les autorisations de ses antécé- 
dents hiérarchiques. Il est aussi possible de superposer plusieurs hiérar- 
chies [Fernandez 80]. Egalement, un sujet peut être un ensemble de tran- 
sactions cataloguées ; l'accés à ces transactions doit alors être aussi pro- 
tégé. 


5.5. — L'attribution de droits 


L'attribution de droits aux sujets sur les objets est un autre pro- 
bléme important. Plus précisément, il est nécessaire de définir qui attri- 
bue les droits. Deux approches sont possibles. Soit, comme dans 
Systéme R, le créateur d'un objet (une relation dans systéme R) devient 
son propriétaire et reçoit tous les droits. Il doit alors disposer de primiti- 
ves du type [Griffiths 76] : 


GRANT «types d'opérations» ON «objet» TO «sujet» 
REVOKE «types d'opérations» FROM «objet» TO «sujet» 


afin de passer et retirer les droits qu'il possède. 


Soit un groupe de sujets particuliers (les administrateurs des bases 
de données) possédent tous les droits et les allouent aux autres par des 
primitives du méme type. La premiére approche est décentralisée alors 
que la deuxiéme est centralisée. Des approches intermédiaires sont possi- 
bles si l'on distingue plusieurs groupes de sujets avec des droits a priori 
[Chamberlin 78]. 


6. CONCLUSION 


Dans ce chapitre, nous avons abordé les problèmes d'intégrité des 
données en face des pannes et de sécurité des données en face des accés 
non autorisés. Plusieurs problémes n'ont cependant pas été abordés, en 
particulier celui de la vérification des contraintes d’intégrité et celui de la 
Sécurité dans les bases de données statistiques. 


La vérification des contraintes d’intégrité est un aspect trés impor- 
tant afin de vérifier la validité des mises à jour et de conserver les don- 
nées cohérentes. La vérification des contraintes de type d'un domaine est 
relativement simple et peut être effectuée à chaque insertion ou mise à 
jour. Par contre, la vérification de contraintes mettant en jeu plusieurs 
tuples ne peut étre en général effectuée que lors de la validation de tran- 
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saction. De nombreuses techniques ont été proposées [Bernstein 80, Gar- 
darin 79, Hammer 78, Nicolas 78], mais seule la technique de modifica- 
tion de questions a donné lieu à réalisation [Stonebraker 75]. 


L'objectif des bases de données statistiques est de donner des résu- 
més sur une population sans permettre à l'utilisateur de déduire des 
informations sur des individus particuliers. Ce type de bases de données 
est important, notamment dans le domaine médical. Il apparait comme 
trés difficile d'éviter les possibilités de déduction d'informations spécifi- 
ques à un individu en corrélant plusieurs résumés, Ainsi le chasseur de 
secrets reste une menace pour les bases de données statistiques [Denning 
79b]. La seule maniére de le perturber est sans doute de lui mentir un peu 
[Demillo 77]. Une vue d'ensemble des résultats dans ce domaine est pré- 
sentée dans [Demillo 78]. 
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IX. L'ÉVALUATION DE QUESTIONS 


1. INTRODUCTION 


La plupart des SGBD, et principalement les SGBD relationnels 
offrent aujourd'hui des langages de manipulation de données assertion- 
nels du type de ceux étudiés au chapitre V. Avec de tels langages, l'utili- 
sateur définit les données qu'il veut visualiser sans fournir les algorith- 
mes d'accés. Le but des algorithmes d'évaluation de questions (d'ailleurs 
aussi de mises à jour, car une mise à jour est une question suivie d'un 
remplacement) est justement de déterminer les algorithmes d'accés. Il est 
essentiel pour un système de fournir des algorithmes d'accès optimisés — 
ou au moins proches de l'optimum — pour les questions les plus fré- 
quentes. Ce n'est pas là un probléme simple comme nous allons le voir 
dans ce chapitre. 


L'évaluation de questions peut étre divisée en trois phases : analyse 
de la question, ordonnancement des opérations élémentaires (en général 
celles de l’algèbre relationnelle) et exécution de ces opérations. Ce chapi- 
tre présente d'abord ces trois phases au paragraphe 2. Le paragraphe 3 
est consacré à l'étude des principales méthodes d'analyse de questions. 
Les trois paragraphes qui suivent développent trois heuristiques 
d'ordonnancement. Enfin, le paragraphe 7 résume les méthodes essen- 
tielles d'exécution de restrictions et de jointures qui sont les opérations 
de base les plus coûteuses de l’algèbre relationnelle. 
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2. LES ÉTAPES DE L'ÉVALUATION 


Dans la plupart des systémes, l'évaluation d'une question s'effectue 
en trois étapes plus ou moins complexes [Apers 82] : 


1. L'analyse de la question consiste à étudier syntaxiquement, et 
parfois sémantiquement, la question de sorte à vérifier sa correction et 
parfois à simplifier le critére de recherche. 


2. L'ordonnancement consiste à décomposer la question en une 
séquence d'opérations élémentaires et à déterminer un ordre plus ou 
moins optimal de ces opérations. Le parallélisme entre certaines opéra- 
tions est possible. Les opérations élémentaires considérées sont générale- 
ment celles de l'algébre relationnelle. L'ordonnancement aboutit à la 
génération d'un plan d'exécution. 


Notion 1 : Plan d'exécution (Request schedule) 
Programme parallèle d'opérations élémentaires à exécuter pour évaluer la réponse à une 
requête. 


3. L'exécution consiste à faire exécuter en parallèle et/ou en 
séquence les opérations élémentaires obtenues lors de l'ordonnance- 
ment, afin d'élaborer le résultat de la question. 


Dans la suite, nous allons étudier successivement les principales 
méthodes proposées pour accomplir ces trois étapes. L'objectif essentiel 
de toutes ces méthodes est évidemment d'optimiser les temps de réponse. 


3. L'ANALYSE DES QUESTIONS 


3.1. — Analyse syntaxique 


Dans un premier temps, une question est syntaxiquement analysée. 
La présence des attributs cités dans le schéma est vérifiée. La correction 
de la qualification de la question est aussi analysée. Celle-ci peut étre 
mise en forme normale conjonctive (ET de OU) ou disjonctive (OU de 
ET), selon qu'elle sera ultérieurement traitée par des opérateurs élémen- 
taires supportant le OU (forme normale conjonctive), ou simplement 
comme plusieurs questions (forme normale disjonctive). Finalement, ce 
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premier traitement est analogue à l’analyse syntaxique d’expressions 
dans un langage de programmaticn. 


3.2. — Analyse sémantique 


3.2.1. — Principes et outils 


Ce type d'analyse a plusieurs objectifs, tels que la détermination de 
la correction de la question, la recherche de questions équivalentes par 
manipulation de la qualification, et aussi la recherche de questions équi- 
valentes à l'aide des contraintes d'intégrité. Ce dernier type d'optimisa- 
tion est d'ailleurs rarement implanté dans les systémes. 


Afin d'illustrer nos propos, nous utiliserons une base de données 
composée de quatre relations : 


ABUS (NOM, NV, QUANTITÉ) 
PRODUCTEUR (NP, NOM, RÉGION) 
VINS (NV, CRU, MILLÉSIME, DEGRÉ) 
PRODUIT (NV, NP) 


qui décrivent respectivement des buveurs ayant bu caractérisés par un 
nom, un numéro de vin bu et une quantité, des producteurs caractérisés 
par un numéro, un nom et une région, des vins caractérisés par un 
numéro, un cru, un millésime et un degré, l'association entre un vin et le 

. producteur qui l'a produit. On considérera par exemple la question 
« quels sont les crus des vins produits par un producteur bordelais en 
1975 ayant un degré inférieur ou égal à 14 ? » ; ainsi, les Bordeaux 1976 
de degré inférieur ou égal à 14 sont donnés par l'évaluation de la ques- 
tion exprimée en QUEL comme suit : 


(Q1) RANGE OF P, V, R, IS PRODUCTEUR, VINS, PRODUIT 
RETRIEVE V. CRU INTO W 
WHERE (V. MILLESIME = « 1976 ») A 
(V.DEGRE < = 14) A (P. REGION = « Bordelais ») A 
(P.NP = A. NP) A (R.NV = V.NV) 


Plusieurs types de graphes (ou plutôt de multi-graphes) sont utilisés 
pour effectuer l'analyse sémantique d'une question. Tout d'abord, le 
graphe de connexion des relations a été introduit par [Wong 76] puis pré- 
cisé par [Ullman 80]. 


L'évaluation de questions 235 


Notion 2 : Graphe de connexion des relations (Relation connection Graph) 

Graphe dans lequel un sommet est associé à chaque référence de relation, où une jointure 
est représentée par un arc entre les deux relations participantes et une restriction par une 
boucle sur la relation à laquelle elle s'applique. 


Dans le cas des langages QUEL ou du calcul relationnel de tuples, 
un nœud est associé à chaque variable. Les arcs sont valués par la clause 
qu'ils représentent. En général, un nœud singulier représentant le résul- 
tat est ajouté au graphe, ainsi que des arcs joignant les variables figurant 
dans le résultat au noeud singulier afin de représenter les projections 
finales. Ainsi, le graphe de connexion des relations de la question Q1 est 
représenté figure IX.1. A noter la difficulté pour représenter des ques- 
tions avec des disjonctions de jointures qui peuvent être modélisées par 
plusieurs graphes. 


(V.MILLESIME = ''1976"') 
A (V.DEGRE < =14) 





P.REGION 


{Bordelais » 


V.CRU 


Résultat 


Fig. IX.1. = Graphe de connexion des relations de la question Q1 


Plusieurs variantes d'un tel graphe ont été proposées, en particulier 
le graphe de la question [Bernstein 79a] où seules les jointures sont maté- 
rialisées par un arc. 


Le graphe de connexion des attributs peut étre défini comme suit 
[Hevner 79]. 


Notion 3 : Graphe de connexion des attributs (Attribute connection graph) 

Graphe dans lequel un sommet est associé à chaque référence d'attribut ou de constante, 
où une jointure est représentée par un arc entre les attributs participants et une restriction 
par un arc entre un attribut et une constante. 





| 
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La figure IX.2 représente le graphe de connexion des attributs de la 
question Ql. 


V.MILLESIME 


Goa) 
= (Bordelais) 





= R.NP 


Fig. IX.2. — Graphe de connexion des attributs de la question Q1 


Une variante introduite dans [Bernstein 79a] est appelée graphe des 
jointures : seules les jointures sont représentées. Une autre variante est 
décrite dans [Rosenkrantz 80], nous appellerons cette variante graphe nor- 
malisé de connexion des attributs. Ce type de graphe est orienté et les 
arcs sont valués par des nombres entiers : un arc du sommet x vers le 
sommet y valué par c représente l'inégalité x < = y + c. Un nœud repré- 
sente un attribut ou une constante. Une égalité du type x — y est repré- 
sentée par deux arcs valués par 0, x > y et y > x. 


Ainsi, la figure IX.3 représente le graphe de connexion des attributs 
normalisé de la question Q1. 


V.MILLESIME (1976) 
V.DEGRE o 
o 
P.REGION | 5 Bordelais) 

9 
(P. NP ER NP 
o 9 
R.NV V.NV 


Fig. IX.3. — Graphe normalisé de connexion des attributs de la question Q1 
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3.2.2. — Correction de la question 


La notion de question correcte est tout d'abord à préciser. Deux 
concepts sont couverts par cette notion : 


1. Une question peut être mal formulée car certaines parties appa- 
raissent inutiles dans la question ; c'est sans doute que l'utilisateur a 
oublié une jointure dans la question. 

2. Une question peut présenter une qualification contradictoire, qui 
ne peut être satisfaite par aucun tuple ; ainsi par exemple la question 
« crus des vins de degré supérieur à 14 et inférieur à 12 ». 


Deux résultats importants ont été établis afin d'éliminer les ques- 
tions incorrectes, dans le cas des questions conjonctives (sans V) avec 
opérateurs de comparaisons =, <, >, <=, >= (pas de x): 

1. Une question est mal formulée si son graphe de connexion des 
relations n'est pas connexe [Wong 76]. 


2. Une question est contradictoire si son graphe normalisé de conne- 
xion des attributs présente un cycle dont la somme des valuations est néga- 
tive [Rosenkrantz 80]. 


3.2.3. - Questions équivalentes par transivité 


Afin de préciser cette notion d'équivalence de questions, nous intro- 
duirons une définition plus précise [Aho 79]. 


Notion 4 : Questions équivalentes (Equivalent queries) 
Deux questions sont équivalentes si et seulement si elles donnant le même résultat pour 
toute extension possible de la base de données. 


Ainsi, quels que soient les tuples (évidemment obéissant aux con- 
traintes d'intégrité) dans la base, deux questions équivalentes exécutées 
au même instant donneront le même résultat. 


Tout d'abord, des questions équivalentes peuvent être générées par 
étude des propriétés de transitivité du graphe de connexion des attributs 
[Gomez 78, Bernstein 79A]. Si l'on considère le graphe normalisé de conne- 
xion des attributs, tout couple d’attributs (x, y) reliés par un chemin x 
— y de somme des valuations c doit vérifier x < = y + c. Ainsi il est pos- 
sible de générer la fermeture transitive de ce graphe. Tous les sous- 
graphes ayant méme fermeture transitive générent des questions équiva- 
lentes, bien qu'exprimées différemment. Ainsi, considérons la question 


| 
| 
| 
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i 
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Q2 : « noms des buveurs ayant bu un Bordeaux de degré supérieur ou 
égal à 14 ». Cette question peut s'exprimer comme suit : 


(Q2) RANGE OF A, R, P, V IS ABUS, PRODUIT, PRODUCTEUR, VINS 
RETRIEVE A. NOM 
WHERE  (A.NV = R.NV) A (R.NV = V.NV) A 
(R.NP = P.NP) A (P. REGION = « Bordelais ») 
A (V.DEGRE > = 14). 


où A, R, P, V désignent respectivement les relations ABUS, PRODUIT, 
PRODUCTEUR, VINS. Le graphe normalisé de connexion des attributs 
de Q2 est représenté figure IX.4. Sa fermeture transitive est représentée 
figure IX.5 et un graphe ayant même fermeture transitive figure IX.6. 
Ainsi la question Q2 peut être posée par la formulation résultant du gra- 
phe de la figure IX.6 (avec les mêmes variables). 


(Q2) RETRIEVE A. NOM 
WHERE  (A.NV = R.NV) A (A.NV = V.NV) A 
(R.NP = P.NP) A (P. REGION = « Bordelais ») 
A (V.DEGRE >= 14). 


La différence est dans le choix des jointures. D’autres expressions 
sont possibles. Le problème est bien sûr de choisir celle qui pourra être 
évaluée le plus rapidement. 


D 








Fig. IX.4. — Graphe normalisé de connexion des attributs de la question Q2 
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i Fig. IX.6. — Graphe ayant même fermeture transitive que celui de la figure IX.4 | 





3.2.4. — Questions équivalentes par intégrité 


n utiliser les contraintes d'intégrité [Grant 80, Hammer 80, King 81, La 


I 

Une autre maniére de générer des questions équivalentes consiste à | 

i 

Chimia 82]. Le probléme peut être posé comme suit. Etant donnée une , | 
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question de qualification Q et un ensemble de contraintes d'intégrité I1, 
I2 ... In, si Q est contradictoire à une contrainte, la question a une 
réponse vide. Sinon, il suffit d'évaluer la « meilleure » qualification, en 
temps d'exécution — éventuellement vide — Q’ qu'il suffit de vérifier 
pour que Q soit vérifiée, c'est-à-dire telle que: 11 AI2A ... AQ’ = Q. 
Le probléme est un probléme de déduction que nous illustrerons simple- 
ment par un exemple. Supposons par exemple que tous les Bordeaux 
soient de degré supérieur à 14, c'est-à-dire que l'on ait la contrainte d'in- 
tégrité (où P désigne un tuple de PRODUCTEUR, R un tuple de PRO- 
DUIT et V désigne un vin) : 


(P. REGION = « Bordelais ») A (P.NP = R.NP) A 
(R. NV = V.NV) = (V. DEGRE > 14). 


Alors, la qualification de la question Q1 est contradictoire avec cette 
contrainte et par suite sa réponse est vide. Par contre, cette contrainte 
permet de simplifier la question Q2 car la condition V.DEGRE > = 14 
est inutile et peut donc étre supprimée. Il n'est pas sür que cette simplifi- 
cation réduise les temps d'exécution... Dans d'autres cas, les contraintes 
d'intégrité permettent d'ajouter des critéres, ce qui peut étre utile pour 
accéder via un index. 


4. L'ORDONNANCEMENT PAR RESTRUCTURATIONS ALGÉBRIQUES 


4.1. — Arbre algébrique 


A partir de la requête analysée, il est possible de générer un arbre 
d'opérations de l'algébre relationnelle (projection, restriction, jointure, 
union, différence...) appelé arbre algébrique. 


Notion 5 : Arbre Algéhrique (Relational algebra tree) 

Arbre représentant une question dont les nœuds terminaux représentent les relations, les 
nœuds intermédiaires des opérations de l'algèbre relationnelle, le nœud racine le résultat 
d'une question, et les arcs les flux de données entre les opérations. 


Plusieurs arbres représentent une même question, selon l’ordre 
choisi pour les opérations. Une méthode de génération simple d'un arbre 
consiste à prendre les prédicats de qualification dans l'ordre où ils appa- 
raissent et à leur associer l'opération relationnelle correspondante, puis à 
terminer par une projection finale pour obtenir le résultat. Cette 
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méthode permet par exemple de générer l'arbre représenté figure IX.7 
pour la question : 


(Q2) RETRIEVE A.NOM 
WHERE  (A.NV = R.NV) A (R.NV = V.NV) A 
(R.NP = P.NP) A (P. REGION = « Bordelais ») 
A(V.DEGRE > = 14) 


Résultat 


T 


V.DEGRE 
>= 14 


P.REGION 
"Bordelais" 


R.NP P.NP 





Å P(PRODUCTEUR) 







R.NV V.NV 


V [VINS] 
ANV RNV 





Fig. IX.7. — Un arbre algébrique 


pour la question Q2 A [ABUS] R [PRODUIT] 


A partir d'un arbre algébrique, il est possible de générer un plan 
d'exécution en parcourant l'arbre, des feuilles vers la racine, Une opéra- 
tion peut être exécutée dès que ses opérandes sont disponibles ; ainsi, si 
l'opération a n'utilise pas les résultats de l'opération b, a et b peuvent 
être exécutées en parallèle. 


On cherche bien sûr à optimiser les temps de réponse, donc à mini- 
miser le temps nécessaire à l'exécution du plan. Le problème est donc de 
générer un plan optimal. Pour cela, il faut optimiser simultanément : 
— le nombre d’opérations d'entrées-sorties, 

— le parallélisme entre les entrées-sorties, 
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— la taille des tampons nécessaires à l'exécution, 
— le temps unité central nécessaire... 


L'optimisation effectuée dépend essentiellement de l'ordre des opé- 
rations apparaissant dans l'arbre algébrique utilisé. Il est donc essentiel 
d'établir des régles permettant de générer, à partir d'un arbre initial, tous 
les arbres possibles afin de pouvoir ensuite choisir celui conduisant au 
meilleur plan. En fait, le nombre d'arbres étant trés grand, on est amené 
à définir des heuristiques pour déterminer un arbre proche de l'opti- 
mum. 


4.2. — Règles de transformation des arbres 

Ces régles ont été précisées pour la premiére fois dans [Smith 75] puis 
développées dans [Ullman 80]. Elles dépendent évidemment des opéra- 
tions relationnelles considérées. Nous considérons ici l'ensemble des 
opérations restriction, projection, jointure, union, différence et énonce- 


rons huit régles illustrées par des figures qui donnent deux schémas 
d'arbres équivalents. 


Régle 1: Commutativité des jointures 


Règle 2: Associativité des jointures 


R3 R1 


R1 R2 R2 R3 
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Règle 4 : Commutation des restrictions et projections 





Nécessaire 

si 

Ai n'est pas un 
des attributs 
Aq ... Ap 







Ai est nécessaire 
si 

A Ai n'est pas un 
des attributs 

A1 Ap 


mm 
| 


R (..Ai..) 


R (..Ai..) 


Règle 5 : Commutation des restrictions et jointures 


| 

\ 

| 

| 
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| R2 L.Bj..) 

b INC 

| Eo | 
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Règle 6 : Commutation des restrictions et unions, ou des restrictions et différences 


| 
| 
| 
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= 
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Règle 7 : Commutation des projections et jointures 


À Nécessaire si 
Ai n'appartient 
pas à A4 ... Ap 
ou 


a Bj n'appartient 
Aj pas à B4 ... Bq 
[ApB 18 n 


Ux. P 
L à 











RylAÏ.) | Rel. Bj.. 


R4(.Ai..) R2(..Bj..) 


Règle 8 : Commutation des projections et unions 


RAA.) Ra. Ai.) | ! 


RIAL)  Rot.Ai.. 
4.3. — Optimisation par descente des opérations unaires 


Une première optimisation simple consiste à exécuter tout d’abord 
les opérations unaires (restriction, projection) puis les opérations binai- 
res. En effet, les opérations unaires sont des réducteurs de la taille des 
relations, alors qu'il n'en est pas ainsi de certaines opérations binaires 
qui ont tendance à accroître la taille des résultats par rapport aux rela- 
tions arguments. Aussi, afin de ne considérer que les arbres à flux de 
données minimum et de réduire ainsi le nombre d’entrées-sorties à effec- 
tuer, on est conduit à descendre les restrictions et projections. De plus, 
quand deux projections successives portent sur une même relation, il est 
nécessaire de les regrouper afin d’éviter un double accès à la relation. 


Les principes précédents conduisent à l’algorithme d'optimisation 
suivant : 
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1. Séparer les restrictions comportant plusieurs prédicats à l'aide de la 
regle 3. 

2. Descendre les restrictions aussi bas que possible à l'aide des régles 4, 5 
et 6. | 

3. Regrouper les restrictions successives portant sur une même relation. 

4, Descendre les projections aussi bas que possible à l'aide des règles 7 et 
8. 

5. Regrouper les projections successives en conservant les attributs res- 
tants et éliminer d'éventuelles projections inutiles qui auraient pu 
apparaitre (projection sur tous les attributs d'une relation). 


En régle générale, une restriction suivie par une projection sont exé- 
cutées simultanément par un méme opérateur de sélection (restriction + 
projection) afin d'éviter plusieurs passes sur une même relation. Il en est 
de méme pour une jointure suivie par une projection. A titre d'illustra- 
tion, cet algorithme a été appliqué à l'arbre représenté figure IX.7. On 
aboutit à l'arbre représenté figure IX.8. Cet arbre n'est pas forcément 
optimal pour au moins deux raisons : la descente des restrictions et pro- 
jections n'est qu'une heuristique et l'ordre des opérations binaires n'a 
pas été optimisé. 













P.REGION 


"Bordelais 


P [PRODUCTEUR] 


R (PRODUIT] — V [VINS] 


Fig. IX.8. — Arbre optimisé 
par descente des restrictions 
et projections A [ABUS] 
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5. L'ORDONNANCEMENT PAR DÉCOMPOSITION 


La décomposition est une stratégie d’ordonnancement appliquée 
dans le système INGRES [Wong 76]. Elle est basée sur deux techniques 
de transformations de questions appelées détachement et substitution. 


5.1. — Le détachement de sous-questions 


5.1.1. — Définition 


Le détachement permet de décomposer une question Q en deux 
questions successives Q1 suivie de Q2, ayant en commun une variable 
unique résultat de Q1. 


Notion 6 : Détachement (Detachment) 
Transformation de question consistant à diviser une question en deux sous-questions 
ayant une seule variable commune. 


"De manière plus formelle, la situation générale où le détachement 
est possible est la suivante. Soit une question Q de la forme : 
(Q) | RANGE OF (X, X, ..., Xn) IS (Ra, Rz..., Rn) 
RETRIEVE T (X, X, ..., Xm) 
WHERE B; (X,, X, ..., Xm) 
AND B, (Xm, Xm + 1 ..., Xn) 
où B, et B, sont des qualifications incluant respectivement les variables 
X, X, ... Xm et Xm, Xm +1 ... Xn, alors que T est un résultat de projection à 
partir des variables X;, X, ... Xm. 


Une telle question peut étre décomposée en deux questions successives, Q1 
suivie de Q2, par détachement : 
(Q1) RANGE OF (Xm, Xm +1, ... Xn) IS (Rm, Rm +1, ... Rn) 
RETRIEVE INTO R'm (T' (Xm)) 
WHERE B, (Xm, Xm + 1, ... Xn) 


où T'(Xm) contient les informations de Xm nécessaires au reste de la 
question : 
(Q2) RANGE OF (X,, X; ... Xm) IS (R, Ro ... R'm) 


RETRIEVE T (X, Xa, ... Xm) 
WHERE B, (X,, Xa, ... Xm). 
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Une question dans laquelle aucun détachement n'est possible est 
dite irréductible. On peut montrer qu'une question est irréductible lors- 
que le graphe de connexion des relations ne peut être divisé en deux clas- 
ses connexes par élimination d'un arc [Wong 76]. 


5.1.2. — Différents cas possibles 


Comme indiqué plus haut, toute technique d'évaluation de question 
doit chercher à exécuter tout d'abord les opérations qui réduisent la taille 
des relations figurant dans la question. Une telle opération est bien sür la 
sélection (restriction suivie de projection), mais c'est aussi la semi- 
jointure [Bernstein 79b]. 

Notion 7 : Semi-jointure (Semi-join) 
La semi-jointure de la relation R par la relation S, notée RIX S, est la jointure de R et S 
projetée sur des attributs de R. 


Autrement dit, le semi-joint de R par S est composé des tuples (ou 
partie de tuples) de R appartenant à la jointure avec S. On peut aussi 
voir la semi-jointure comme une généralisation de la restriction : cette 
opération restreint les tuples de R par les valeurs qui apparaissent dans 
le (ou les) attribut(s) de jointurede S (par la projection de S sur ce (ou ces) 
attribut(s). La semi-jointure R XS est une opération qui réduit la taille de R. 


Le détachement permet de faire apparaitre d'une part les restric- 
tions, et d'autre part les semi-jointures. Ce sont les deux seuls cas de 
détachement possibles. Nous allons illustrer ces détachements sur la 
question (Q2) vue au paragraphe 3.2.3 : 


RETRIEVE A. NOM 

WHERE  (A.NV = R.NV) A (R.NV = V.NV)A 
(R.NP = P.NP) A (P. REGION = « Bordelais ») 
A (V.DEGRE >= 14). 


Le graphe de connexions des relations de cette question est repré- 
senté figure IX.9. 


ANV = RNV 







R.NP = P.NP 
P.REGION = ''Bordelais'" 






V.DEGRE 
>= 14 Fig. IX.9. — Graphe de connexion 


Résultat - 1 
des relations de la question Q2 
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Tout d’abord, les deux sélections : 


(Q21) RETRIEVE V.NV INTO V 
WHERE  (V.DEGRE >= 14). 


(Q22) RETRIEVE P.NP INTO P' 
WHERE  (P.REGION = « Bordelais ») 


peuvent étre détachées. 


En faisant maintenant varier V sur la relation V' résultat de Q21 et P sur 
la relation P’ résultat de Q22, il reste à exécuter la question : 


(Q2) RETRIEVE A. NOM 
WHERE  (A.NV = R.NV) A (R.NV = V.NV) A 
(R.NP = P.NP) 


De cette question peut être détachée la sous-question : 


(Q23) RETRIEVE R.NV, R.NP INTO R' 
WHERE  R.NV = V.NV 


Q23 est bien une semi-jointure. En faisant maintenant varier R sur la 
relation R' résultat de Q23, il reste la question : 


(Q"2) RETRIEVE A. NOM 
WHERE  (A.NV = R.NV) A (R. NP = P.NP) 


Il est encore possible de détacher une semi-jointure : 


(Q24) RETRIEVE R.NV INTO R" 
WHERE  (R.NP = P.NP) 


Il ne reste plus qu'à exécuter une derniére semi-jointure, en faisant varier 
R sur R” résultat de Q24 : 


(Q25) RETRIEVE A.NOM 
WHERE (ANV = R.NV) 


Finalement, la question Q a été décomposée en un arbre de sélection et 
semi-jointure représentés figure IX.10. 


Toutes les questions ne sont pas ainsi décomposables en sélections 
suivies par des semi-jointures. Il est bien sür toujours possible de déta- 
cher les sélections. Par contre [Bernstein 79a] a montré que seules les 
questions dont les graphes de connexion aprés élimination des boucles 
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(détachement des sélections) sont des arbres, peuvent être décomposés en 
séquences de semi-jointures (d’ailleurs pas uniques). Les questions irré- 
ductibles présentent donc des cycles dans le graphe de connexion des 
relations. Attention, certaines questions peuvent paraître irréductibles 
alors qu'il existe des questions équivalentes décomposables par détache- 
ment [Bernstein 79a]. 


li 
Q24 Semi-jointures 
Q23 
| Sélections 
Fig. 1X.10. — Décomposition Q21 Q22 


par détachement de Q2 


5.2. — La substitution de tuples 


Il existe donc des questions irréductibles par détachement : celles 
qui présentent des cycles dans le graphe de connexion des attributs. Par 
exemple, la question Q3 qui recherche les couples (noms de buveurs, 
noms de producteurs) tels que le buveur ait bu un vin du producteur : 


(Q3) RANGE OF A, R, P IS ABUS, PRODUIT, PRODUCTEUR 
RETRIEVE A. NOM, P. NOM 
WHERE (A. NV = R.NV) A (R.NP = P.NP) 


est une question irréductible. Son graphe de connexion des relations pré- 
sente en effet un cycle (fig. IX.11). 


A.NOM 





Résultat R.NP 


P.NP 
Fig. IX.11. — Graphe de connexion des relations de la question Q3 


Afin de résoudre les questions irréductibles, le système INGRES 
applique une méthode trés simple : une des relations est balayée séquen- 
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tiellement. Pour chaque tuple ainsi obtenu, la sous-question générée par 
substitution de la variable par le tuple lu est traitée par détachement, puis 
encore par substitution de tuples si une sous-question irréductible appa- 
rait à nouveau. L'algorithme est donc ainsi récursif [Wong 76]. 


Un des problémes généré par un tel algorithme est le choix de la 
variable de substitution. Ce choix n'est pas évident. Disons simplement 
que la substitution de tuples consiste à remplacer une question à n varia- 
bles Q (XI, X2, ... Xn) par des sous-questions Q (a, X2, ... Xn) où a 
décrit la relation R, représentée par la variable X1. Le nombre de sous- 
questions générées est donc le nombre de tuples de R,. Afin de limiter ce 
nombre, on a apparemment intérêt à choisir la variable associée à la plus 
petite relation pour la substitution. 


5.3. — Bilan 


La décomposition est une heuristique d'ordonnancement originale 
qui consiste à exécuter tout d'abord les sélections, puis à ordonner les 
jointures de sorte à faire apparaître les semi-jointures possibles. Du fait 
que les semi-jointures réduisent les tailles des relations, on peut ainsi 
espérer réduire les tailles des résultats intermédiaires et donc le nombre 
d'entrées-sorties. Cette heuristique apparaît donc comme supérieure à 
l'ordonnancement par restructuration algébrique sans ordonnancement 
des jointures, tel qu'il a été étudié au paragraphe 4.3. Le vrai probléme 
est celui d'ordonnancer les jointures, et plus généralement les opérations 
binaires : la décomposition est une premiére approche qui ne nécessite 
aucune estimation de la taille des résultats des jointures. 


6. ESTIMATION DU COÜT D'UN PLAN D'EXÉCUTION 


6.1. — Objectifs 


Une solution simple pour choisir le meilleur plan d'exécution 
consiste à les générer tous, à estimer le coüt d'exécution de chacun et à 
choisir celui de moindre coüt. Malheureusement, une telle stratégie se 
heurte à deux difficultés : 


1. Le nombre de plans d'exécution possible est trés grand. Cet inconvé- 
nient peut être pallié en éliminant a priori tous les plans qui font appel 
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à l'opération de produit cartésien [Selinger 79] ; en effet, la commu- 
tation de jointures peut générer des produits cartésiens qui en général 
multiplient les tailles des relations à manipuler. On a donc tout intérét 
à éviter les plans d'exécution contenant des produits cartésiens. Une 
autre possibilité encore plus restrictive est d'éliminer tous les plans 
qui n'effectuent pas les sélections dés que possible [Bellahsene 82]. 
2. L'estimation du coüt nécessite d'une part la connaissance de la taille 
des résultats intermédiaires de toutes les opérations considérées, 
d'autre part la prise en compte des chemins d'accés aux relations 
(index, lien...) qui change directement ces coüts. Nous allons ci- 
dessous examiner les résultats concernant ces deux problémes. 


Une autre approche a été proposée dans [Nguyen 79, Nguyen 80]. 
En effet, toutes les méthodes discutées jusque là sont basées sur l'idée de 
générer un plan d'exécution a priori, avant de l'exécuter. De telles 
méthodes d'ordonnancement sont appelées statiques. Une approche 
dynamique consistant à contruire le plan au fur et à mesure de l'exécu- 
tion a été proposée pour un systéme réparti. Une telle approche reste à 
appliquer dans un contexte centralisé. 


6.2. — Estimation de la taille des résultats 


L'estimation de la taille des résultats est basée sur un modèle de dis- 
tribution des valeurs des attributs dans chacune des relations, ainsi 
qu'éventuellement des corrélations entre les valeurs d'attributs. Le 
modèle doit être conservatif [Richard 81], c'est-à-dire que pour toute 
opération de l’algèbre relationnelle, il faut être capable, à partir des 
paramètres décrivant les relations arguments, de calculer les mêmes 
paramètres pour la relation résultat. 


Le modèle le plus simple est celui qui suppose l'uniformité de la dis- 
tribution des valeurs et l'indépendance des attributs. De telles hypothé- 
ses sont utilisées dans Systéme R [Selinger 79] et dans SDD.1 [Bernstein 
81]. Ces modèles nécessitent de connaître : 


— la taille de chaque attribut, 
— ]e nombre de valeurs distinctes de chaque attribut, 
— le nombre de tuples de chaque relation, 

etc. 


Un modéle basé sur des probabilités, incluant les probabilités condi- 
tionnelles pour exprimer les dépendances entre attributs, a été proposé 
par [Demolombe 80]. Une estimation combinatoire de la taille des pro- 
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jections prenant en compte les dépendances fonctionnelles est présentée 
dans [Gelenbe 82]. La possibilité d'utiliser de tels modèles dans les systè- 
mes réels reste à démontrer. 


6.3. — Prise en compte des chemins d'accès 


Les chemins d'accés (index, liens...) sont un facteur essentiel à pren- 
dre en compte dans l'évaluation de questions. Ils peuvent étre considérés 
seulement lors de l'évaluation des opérations élémentaires (sélection, 
jointure), mais devraient aussi intervenir dans le choix du plan d'exécu- 
tion. Ainsi, Systéme R utilise les chemins d'accés pour choisir le plan 
d'exécution d'une question. 


Dans Systéme R [Selinger 79], la détermination du plan d'exécution 
est effectuée en affectant un coüt à chaque plan candidat : 


COUT = NOMBRE D'ACCES PAGE + W * NOMBRE D'APPELS 
INTERNES 


Le nombre d'appels internes donne une estimation du temps unité cen- 
trale nécessaire à l'exécution du plan, alors que le nombre d'accés page 
évalue le nombre d'entrées-sorties nécessaires à l'exécution du plan. W 
est un facteur ajustable d'importance relative du temps unité centrale et 
du temps entrées-sorties. Le nombre d'accés page est estimé par évalua- 
tion d'un facteur de sélectivité F pour chacun des prédicats associés à 
une opération de l'algébre relationnelle. Le nombre d'accés pour l'opé- 
ration est calculé en fonction de F et de la taille des relations opérandes. 
Le calcul de F tient compte de la présence ou non d'index ; ainsi, par 
exemple, le facteur de sélectivité d'une sélection : 


ATTRIBUT = Valeur 
est évalué par : 
F = 1/Nombre d'entrées dans l'index 


s’il existe un index, sinon par : 
F = 1/10. 


Tous les plans, à l'exception de ceux contenant des produits cartésiens, 
sont évalués. Le plan de coüt minimum est retenu. 
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7. EXÉCUTION DES SÉLECTIONS ET JOINTURES 


7.1. — Exécution des sélections 


7.1.1. — Cas sans index 


L'exécution des sélections sans index s'effectue par balayage 
séquentiel du fichier contenant la relation sur laquelle porte la sélection. 
Pour chaque tuple, les attributs pertinents doivent étre comparés avec les 
valeurs de sélection. Des processeurs matériels spécialisés appelés filtres 
ont été proposés pour accomplir de telles opérations simultanément à la 
lecture des données sur disques [Bancilhon 80, Rohmer 81]. 


7.1.2. — Cas avec index 


L'exécution des sélections, quand tous les attributs du critère de sélec- 
tion sont associés à un index primaire ou secondaire, s'effectue par inter- 
section et union de listes d'identifiants de tuples (clés ou adresses). Par 
exemple, considérons la relation : 


VINS (NV, CRU, MILLESIME, DEGRE) 
et supposons qu'il existe un index sur chacun des attributs. La sélection : 


(CRU = « Chablis ») A (MILLESIME > = 1981) A (DEGRE = 12) 


s'effectuera par les opérations ensemblistes sur listes : 


Cn(MIUM2nD 


` 


où : 
— C est la liste des identifiants de vins « Chablis » 
— Mi est la liste des identifiants de vins « 1981 » 
— M2 est la liste des identifiants de vins « 1982 » 
— D est la liste des identifiants de vins de degré 12. 


On suppose qu'il n'existe pas de vins de millésime aprés 1982. 


Les opérations d'intersection seront effectuées dans l'ordre des tail- 
les croissantes afin de réduire les temps d'exécution [Apers 82]. 


Quand certains attributs seulement sont indexés, on a en général inté- 
rêt à accéder d'abord aux index, puis à tester les prédicats restant sur les 
tuples obtenus par les opérations ensemblistes sur listes d'identifiants. Ceci 
n'est cependant pas possible si un prédicat sur un attribut non indexé appa- 
rait en disjonction de tous les autres. Une stratégie d'accès mixte par index 
et balayages est ainsi proposée dans [Astrahan 75]. 
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7.2. — Exécution des jointures 


Les algorithmes d’exécution de jointures sont étudiés systématique- 
ment dans [Valduriez 81], puis systématiquement étendus dans un envi- 
ronnement multiprocesseurs dans [Gardarin 82], enfin au cas des semi- 
jointures dans [Valduriez 82]. Nous résumons ici les algorithmes mono- 
processeurs essentiels, en supposant avoir à exécuter la jointure de deux 
relations R1 et R2 selon le prédicat RI.A = R2.B. |R1| et |R2| sont les 
nombres de pages de chacune des relations, R1 est supposée être la plus 
petite relation. 


7.2.1. — Cas sans index 


La méthode la plus simple [Gotlieb 75] consiste à comparer chaque 
tuple de la première relation avec tous les tuples de la deuxième, successi- 
vement. Ainsi, tous les couples de tuples du produit cartésien sont com- 
posés et la jointure est formée pour chaque couple vérifiant le prédicat 
de jointure. L'algorithme est constitué de deux boucles imbriquées et est 
de ce fait appelé algorithme des boucles imbriquées. Le nombre 
d’entrées-sorties exigé par cet algorithme est | R1] * |R2| + |R1|. Ceci 
est souvent prohibitif. 


Une méthode plus efficace consiste à trier les deux relations sur 
Pattribut de jointure, puis à effectuer la fusion des résultats sur l'attribut 
de jointure pour composer le résultat final. Cette méthode est appelée 
méthode par trifusion. Le coüt d'un tel algorithme utilisé dans Systéme 
R [Astrahan 76] est : 


2 |R1| Log |R1| + 2 |R2| Log [R2] + |R1| + |R2| 


Une autre méthode utilisée dans Systéme R est /a méthode multi- 
passe. Cette méthode utilise un parcours multiple des deux relations. Les 
tuples ayant les plus petites valeurs pour l'attribut de jointure sont char- 
gés dans une zone de travail en mémoire centrale. La deuxième relation 
est ensuite balayée en comparant chaque tuple à ceux de la zone de tra- 
vail pour effectuer la jointure. Puis, une deuxième passe est effectuée : 
la zone de travail est à nouveau chargée avec les tuples écartés lors de la 
première passe et le traitement est répété. Des passes successives sont 
ainsi exécutées jusqu'à épuisement de la premiére relation. Le nombre 
d'entrées-sorties nécessaires dépend de la taille de la zone de travail ; si 
celle-ci contient M pages, le nombre de passes est |RI | / Met le nombre 
d'entrées-sorties est : 


([R1] + |R2]) [R1] / M 
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Une méthode efficace est décrite dans [Stonebraker 76]. Cette 
méthode appelée méthode par hachage consiste à hacher la plus petite 
relation, ici R1, sur l'attribut de jointure et à composer ainsi un fichier 
aléatoire. Puis la deuxième est balayée séquentiellement ; pour chaque 
tuple, on tente d’accéder au fichier aléatoire ; si l'accés est accepté, des 
tuples de la jointure sont formés avec les tuples accédés (en général plu- 
sieurs). En supposant que chaque page contienne a articles et que le 
fichier aléatoire puisse être créé en a |R1 | entrées-sorties, le coût de cet 
algorithme est : 


|R1| + a [Ri] + |R2| + a |R2| 


L'algorithme peut étre optimisé par utilisation de tableaux de bits 
[Babb 79] construit lors du hachage de la première relation : un tableau 
de n bits résulte du hachage de la première relation R1 sur l'attribut de 
jointure A par une fonction de hachage g sur [0—n]. Le bit g(A) du 
tableau est positionné pour chaque article. Lors du balayage de la 
deuxième relation, le fichier aléatoire n'est accédé que pour chaque arti- 
cle tel que g(B) = 1, où B est Pattribut de jointure de R2. Ainsi, si j est le 
nombre de tuples par page moyen de R2 participant à la jointure, on 
peut espérer réduire le nombre d'entrées-sorties à: 


|R1| + a [R2| + |R2| + j |R2] 


Finalement, il a été montré [Valduriez 82] que dans les cas où la 
taille de la jointure n'atteint pas 80 % de celle du produit cartésien des 
deux relations, il était avantageux d’exécuter les deux semi-jointures 
R1 X R2 et R2X RI puis la jointure des résultats, plutôt que directe- 
ment les jointures. Ceci résulte du fait qu’un algorithme de semi-jointure 
peut être dérivé de l’algorithme de jointure par hachage, en remplaçant 
le fichier aléatoire par la liste des valeurs de l’attribut de jointure de la 
relation dont on ne conserve aucun attribut. Cette liste tient en général 
en mémoire [Babb 79]. 


7.2.2. — Cas avec index 


Dans le cas où une seule des relations est indexée sur l’attribut de 
jointure, l’algorithme est analogue à la méthode par hachage, à ceci près 
que le fichier aléatoire est remplacé par le fichier indexé. On balaie donc 
séquentiellement le fichier non indexé, et on accède pour chaque article 
au fichier indexé. 
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Dans le cas où les deux fichiers sont indexés sur les attributs de join- 
ture, il suffit de réaliser la fusion des index pour obtenir les couples d'i - 
dentifiants de tuples participant à la jointure [Gotlieb 75]. 


8. CONCLUSION 


Dans ce chapitre, nous avons étudié les principaux algorithmes 
d'analyse, d'ordonnancement et d'exécution de questions. Ces algorith- 
mes et leurs bons emplois conditionnent les performances des systémes 
basés sur des langages assertionnels. Le sujet est encore largement 
ouvert. En particulier, la recherche des questions équivalentes et l'utilisa- 
tion de modéles d'estimation des tailles sophistiqués n'ont encore point 
démontré ni leurs intéréts, ni leurs limites. 
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X. CONCLUSION 


1. BILAN ET PERSPECTIVES 


Nous avons jusque-là étudié successivement l’architecture, les 
modèles et les langages, les algorithmes essentiels des SGBD existants. 
Nous nous sommes efforcés de dégager les notions et les principes fonda- 
mentaux de ces systèmes. Bien que nous espérons avoir cerné assez com- 
plètement les problèmes, nous sommes loin d’avoir clos le sujet qui 
continue à se développer rapidement. 


Depuis les années 60, les SGBD évoluent sans cesse. A chaque géné- 
ration, ils intégrent de nouvelles fonctionnalités sans oublier les ancien- 
nes tendant ainsi à réduire et simplifier les programmes d'application. 
Trois axes canalisent actuellement les directions essentielles des recher- 
ches et développements : les bases de données réparties, les bases de don- 
nées multi-media, et les bases de connaissances. Ci-dessous, nous exami- 
nons rapidement ces trois thémes. 


2. LES BASES DE DONNÉES RÉPARTIES 


La décentralisation des systèmes informatiques se heurte 
aujourd’hui aux problèmes de la répartition des données. Une première 
approche consiste à concevoir des Systèmes de Gestion de Bases de Don- 
nées Réparties (SGBDR) qui assurent globalement la cohérence, la sécu- 
rité, l'intégrité, la fiabilité des données géographiquement disséminées 
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sur plusieurs systèmes. Suivant cette direction, des SGBDR ont été cons- 
truits et sont aujourd’hui sur le point d’être commercialisés. D’un autre 
côté, les machines de bases de données basées sur des architectures origi- 
nales et des technologies nouvelles s'annoncent comme un outil privilé- 
gié pour gérer des données réparties. Plusieurs sont déjà annoncées com- 
mercialement et peuvent collaborer autour de réseaux locaux. Finale- 
ment, une derniére approche consiste à partir de bases de données exis- 
tantes et de SGBD classiques, à rechercher une base sémantique com- 
mune entre les données, et à permettre ainsi la coopération de bases de 
données existantes. 


Les problémes essentiels posés par les bases de données réparties 
sont les suivants : 


— conception d'architectures de systémes, 

— spécification de protocoles de coopération et de contrôle d'exécution 
répartie, 

— contróle des accés concurrents aux données réparties, 

— maintien de l'intégrité des données réparties en présence de pannes et 
d'arréts de machines, 

— optimisation des temps de traitement des requétes, en particulier 
minimisation des transferts réseau, 

— maintien de copies multiples, 

— conception de bases de données réparties et choix de la répartition 
des données, 

— coopération sémantique entre bases hétérogènes conçues séparément. 
De nombreuses solutions ont été proposées dont l'étude dépasse le cadre 
de ce livre. 


3. LES BASES DE DONNÉES MULTI-MEDIA 


Les SGBD étudiés jusqu'ici permettent de traiter des bases de don- 
nées structurées, c'est-à-dire découpées en articles ou tuples composés 
d'attributs de format plus ou moins fixe. 


Bien que les données structurées répondent bien aux besoins de la 
gestion, d'autres types de données sont tout aussi répandus, voir plus : 


— les bases de données textuelles sont composées de textes libres en for- 
mat faiblement structuré (paragraphes, introduction, conclusion...) et 
d'informations descriptives (titre, auteurs, mots-clés, références...) ; 





Conclusion 261 


— les bases d'images contiennent des images codées sous forme de 
matrices de points ; elles devraient permettre la gestion d'un nombre 
important d'images ainsi que de données descriptives plus ou moins 
structurées ; 

— ]es bases cartographiques contiennent des cartes géographiques stoc- 
kées en représentation polygonale (stockage des coordonnées des som- 
mets des différents polygones composants) ou cellulaires (stockage des 
caractéristiques de chaque cellule élémentaire composant la carte). 


Les bases de données multi-media devraient permettre le mixage de 
textes, d'images, de cartes et figures, ainsi que de données structurées et 
les conversions automatiques d'un support à un autre. 


Leur développement souléve de nombreux problémes, en particu- 
lier : 
— codage et compactage des informations stockées, stockage sur dis- 
ques optiques, 
— saisie, visualisation et restitution des documents, 
— recherche à partir de critères textuels mais aussi par repérage visuel 
(navigation visuelle), 
— interprétation intelligente des textes et des images de sorte à générer 
des descriptifs structurés (relations), 
— génération d'images et de textes à partir de descriptifs structurés 
(relations). 


Les deux derniers points sont sans doute les plus difficiles et font 
largement appel aux techniques d'intelligence artificielle et de reconnais- 
sance de formes souvent encore insuffisamment développées pour résou- 
dre tous les problémes. 


4. LES BASES DE CONNAISSANCES 


Les bases de connaissances sont les bases de données utilisées par /es 
systèmes experts. Un système expert est un aide au raisonnement humain 
et à la prise de décision dans un domaine spécifique, par exemple le dia- 
gnostic médical, l'électricité, ou la conception de bases de données,.. 
Une base de connaissance se compose en général de faits qui peuvent être 
stockés sous forme de tuples, de régles (généralement stockées sous 
forme de formules logiques) qui permettent de déduire des conclusions à 
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partir de prémices, et aussi de commentaires permettant d’expliquer les 
raisonnements. 


Outre tous les problèmes rencontrés précédemment, notamment 
pour ce qui concerne les bases de données relationnelles et multi-media, 
les bases de connaissance nécessitent l'enrichissement du systéme avec 
des possibilités de raisonnement dans un univers incertain et incomplet, 
ainsi que la communication avec l'usager dans un langage quasi naturel. 
Ainsi, une base de connaissances doit pouvoir répondre à des questions 
exprimées en francais sur des faits non contenus dans la base, mais quise 
déduisent plus ou moins directement des régles de production et des faits 
de la base. C'est sans doute là un des domaines de recherche des plus 
prometteurs pour le futur. 
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Les bases de données sont aujourd'hui une part importante des 
systémes informatiques. Leur gestion qui s'appuie sur une théorie 
solide, nécessite la mise en ceuvre d'un ensemble d'algorithmes 
sophistiqués et optimisés, et demande le: développement d'archi- 
tectures spécialisées. L'expérience et le bon sens ne suffisent donc 
plus à la construction d'un Systéme de. Gestion de Bases de 
Données. Dans cette optique, cet ouvrage propose une synthése 
des principaux résultats concernant des algorithmes de gestion de 
bases de données, en partant des systémes simples, utilisés quoti- 
diennement, pour aller jusqu'aux problèmes qui restent encore du 
domaine de la recherche. 


Ce livre s'adresse à la fois aux concepteurs et aux utilisateurs des 
systèmes de bases de données, aux étudiants des Universités et des 
Grandes Ecoles se spécialisant en informatique et aux chercheurs 
débutant en bases de données. Les notions essentielles sont claire- 
ment dégagées tout au long de l'exposé, ce qui devrait faciliter 
l'accessibilité au vocabulaire souvent hermétique des spécialistes 
de bases de données. 
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